Split fsverity_init in two phases.

First load the verified keys, and then only lock the keyring after apexd
has run. This is in preperation for on-device signing, which will need
to add another key to the fs-verity keyring before it's locked.

Note that I've moved loading of the verified keys up a bit; fsverity_init
used to load keys from Keymaster, but it currently doesn't, so there's
no need to wait for it.

Bug: 165630556
Test: boot, cat /proc/keys
Change-Id: I077673575ae3dafcf3126d8c544fe7f8d34c0225

rootdir/init.rc

@@ -585,6 +585,9 @@ on late-fs
     # HALs required before storage encryption can get unlocked (FBE/FDE)
     class_start early_hal
 
+    # Load trusted keys from dm-verity protected partitions
+    exec -- /system/bin/fsverity_init --load-verified-keys
+
 on post-fs-data
     mark_post_data
 
@@ -826,6 +829,9 @@ on post-fs-data
     wait_for_prop apexd.status activated
     perform_apex_config
 
+    # Lock the fs-verity keyring, so no more keys can be added
+    exec -- /system/bin/fsverity_init --lock
+
     # After apexes are mounted, tell keymaster early boot has ended, so it will
     # stop allowing use of early-boot keys
     exec - system system -- /system/bin/vdc keymaster early-boot-ended
@@ -1007,9 +1013,6 @@ on boot
 
     class_start core
 
-    # Requires keystore (currently a core service) to be ready first.
-    exec -- /system/bin/fsverity_init
-
 on nonencrypted
     class_start main
     class_start late_start