Fix some bugs in FRP hardening

ebiggers@ identified some problems:

1. The formatting of the persistent data block was incorrect, it
   shortened the FRP challenge section by the size of the FRP
   secret and magic, but then failed to advance the channel write
   position past them, causing subsequent sections to be written
   at the wrong locations.  The data being written to incorrect
   locations was all zeros and it seems unlikely that this could
   have caused any problems, but this fixes it.
2. `writeFrpMagicAndDefaultSecret()` failed to recalculate and
   write the digest, meaning that the PDB would subsequently be
   viewed as corrupted and reformatted on the next boot in some
   obscure cases.
3. `setFactoryResetProtectionSecret()` failed to check that the
   caller has permission to configure FRP.  This isn't strictly
   necessary (nor is the similar check on
   `deactivateFactoryResetProtection()`, but it's also not the
   case that anyone without the permission needs to be calling
   these methods.
4. There was a bug in the FRP secret file display in the status
   command of the persistent_data_block shell command.
5. `deactivateFrpWithFileSecret()` logged a warning if the secret
   file was not found, but this could happen in correct
   operation, so it should be an informational log.  (In general
   FRP hardening makes PDBService too noisy, but this is good in
   the short term; logging will be reduced in the future).

Test: atest PersistentDataBlockServiceTest
Bug: 290312729
Change-Id: Ief505a634d355a97bb6b99efc52cef68649a025f