init.rc: fix (re)starting apexd on FDE devices

On first boot, FDE devices hang on the command
'wait_for_prop apexd.status activated'.  This is because apexd was
already started with the tmpfs /data, then was stopped by
vold.decrypt=trigger_shutdown_framework.  Then when apexd is started
again with the real /data, it sees that apexd.status="ready" already, so
it doesn't consider itself to be starting from scratch again.  So it
doesn't move apexd.status back to "activated" as expected.

Fix the above by resetting apexd.status to its initial value of the
empty string before trying to start apexd in the post-fs-data trigger.
Note that this also takes care of the userspace reboot case which was
previously handled in the userspace-reboot-requested trigger.

Also, FDE devices hang at the same place on non-first boots with default
encryption (i.e., when no PIN is set) because apexd is still running
after having been started with the tmpfs /data.  This is because
vold.decrypt=trigger_shutdown_framework isn't run in that case, but
rather vold manually kills processes that have open files on /data --
which doesn't include apexd.  But, apexd should be restarted too.

Fix that by using 'restart apexd' rather than 'start apexd'.

Note that these changes are needed even though FDE devices don't support
updatable APEXes, as apexd is needed regardless.

This is one of a set of changes that is needed to get FDE working again
so that devices that launched with FDE can be upgraded to Android 12.

Bug: 186165644
Test: Tested FDE on Cuttlefish.  Also tested userspace reboot (with FBE)
Change-Id: I4fa57cf15d77b64d1167eaf966347d2a9d6a9b72