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