Improve practical performance of key monitoring.

This change fixes:
1) The potential for there to be a period between when the pool is last
   regularly checked and when the expired keys are cleaned out by making
   GenerateRkpKeyService much more proactive about triggering the
   reprovisioning process. It now bases the decision based on the same
   logic as the JobSchedule'd code, instead of just trying to act as an
   absolute last chance stopgap.

2) Unnecessarily overeager provisioning. The code will now allow the
   number of unassigned keys to drop below the "ideal" amount set by the
   server and avoid reprovisioning until a minimum remaining threshold
   is crossed. That threshold is currently set to 25% of the ideal
   amount. E.g. a system that is instructed to keep 20 extra attestation
   keys available for assignment won't trigger reprovisioning to top up
   the key pool unless fewer than 5 remain. This does not change the
   behavior when keys are expiring.

This change also refactors the code a bit to follow DRY, while also
increasing the testability of the logic that determines if provisioning
is needed.

Bug: 223489842
Test: atest RemoteProvisionerUnitTests
Change-Id: Idbd767202c30a24e3522ff431dec2d66d2ef631b
5 files changed