Enhance DB recovery logic

Enhance DB recovery logic

"If we are wise, let us prepare for the worst."
					- George Washington

Previously, the logic of DB recovery was:

1. Remove the "-recovered" file flag, IF it survived reboot (shouldn't)
2. Check DB for corruption
3. IF corruption occured, then:
   a. Replace original DB with fallback made at image creation
   b. Create the "-recovered" file next to DB file that signals rest of the system some apps may be missing

If sudden poweroff happens between 3a and 3b, system will not get informed
about missing app installation data.

This patch changes order of operations 3a and 3b, and also removes
operation number 1. From now on, the system-level scripts responsible
for recovery should remove the flag, when full recovery was complete.

Changing order of 3a with 3b ensures the flag is created when
DB error was found and is not prone to sudden power-off.

The flag is meant to be used for file-existance signalling of the need
to reinstall apps that were not in the backed-up DB. Since its existence
can trigger app installation, which in turn, can launch & use security-manager
(which will also attemt to access the DB), it MUST be ensured that rules-loader
is not running concurrently with any other processes/services that may use security-manager's DB
(the recovery of DB from fallback/backup has to be complete). This is achieved
by systemd's "Before=" service option in rules-loader service file which prohibits
security-manager's socket & service start before rules loader-ends operation.

Change-Id: I472c09d9398f69a97e118b69aad61dc016e3d22d