StorageKeyRotationBackend
What a persistent storage adapter provides so StorageKeyRotationManager can rotate its storage key (docs/storage-key-rotation.md). The manager owns the order of the steps and the rules between them; the backend owns the persisted rotation state, its transactions, the records and the proof that no record uses a key.
Every method except exclusive is one atomic storage transaction. A transition method is a compare-and-set: it changes the persisted state only if it still equals from, and otherwise throws IllegalStateException and changes nothing. A failure rolls back the whole call. Transition methods never call the key provider; the manager does that between them.
Functions
RETIRING to STABLE, after the retiring key was removed from the provider.
Runs block exclusively of every other operation on this storage (other rotation steps and every storage transaction). Throws IllegalStateException if called inside a storage transaction. block runs outside any transaction, because it calls the key provider.
The authoritative key reference scan: for every key ID, how many sealed values in the storage name it. Reads every location that holds sealed records, including key checks; a value that is not a well-formed record throws.
MIGRATING to RETIRING, in one transaction: drops whatever only the retiring key needed for opening, runs keyReferences and passes the result to requireRetirable, and commits only if it returns. From then on the storage no longer needs the retiring key.
Re-encrypts up to maxRecords records that are not sealed with the current key, in one transaction. A record that fails to open fails the whole batch. Returns how many such records remain.
STABLE to PREPARING: records nextKeyId as the allocated key and as the new key ID high-water mark, in one commit, so it is never allocated twice.
How many records are not sealed with the current key.
The persisted rotation state.