This refactors HandleImminentDataWipe to address some shortcomings
discovered through testing. Previously, it always called
CreateSnapshotsAndLogicalPartitions, which meant trying to use snapuserd
even if completely unnecessary.
Instead we now peek at the update state and eliminate the "easy" cases
ahead of time. These are "none", "initiated", and "unverified" when
either a rollback happens or there is no forward merge indicator. In
this case we simply return early and allow the wipe to continue
(disabling the current slot if necessary).
The hard case, when a merge is needed, is still handled within
ProcessUpdateStateOnDataWipe. However it's no longer recursive, and it
can assume a merge is about to initiated or already in progress.
In all cases except a merge failure, we change the update state to None
to clear any roadblocks update_engine or the bootloader might encounter.
A merge failure, however, still blocks a data wipe. The way to recover
from this is adb sideload.
Bug: 350613336
Test: vts_libsnapshot_test
wipe in INITIATED state, no merge
wipe in UNVERIFIED state, no merge
wipe in UNVERIFIED + rollback state, no merge
wipe in MERGING state, merge
Change-Id: I387aabcfa6304118be88ddbb85842111d5c2ef6a
c85af55952