Token PKI staging

[jessepeterson]

This change addresses a race condition of sorts.

At WWDC23 Apple announced "Access Management" — a way to have better management controls around Managed Apple ID services such as iCloud. This works with the MDM protocol utilizing the "GetToken" MDM check-in request which returns a.. token. The token utilized for MAID Access Management is a JWT signed by the DEP server's private key used for the DEP authentication PKI exchange. We started an implementation of this in #24.

However this means the DEP private key is an "actively used" bit of data for these token signing events (which could happen at any time — the devices request this when they need it). In NanoDEP every time you request the DEP token PKI (to upload a new certificate/public key to the ABM/ASM/BE portals) we always generate a new key pair. I.e. the store private key is overwritten with a new one right then.

So there is a gap of time between two events between which the private key won't match what Apple is expecting. Between the event of the administrator requesting a new DEP certificate from NanoDEP and the event of the administrator uploading the certificate to Apple and downloading the encrypted tokens a device could request a new DEP token which will not be signed correctly.

To address this we create the notion of a "staging" key pair for the DEP PKI exchange. With this PR when you request a certificate you still generate a key pair for each request. However it is only the "staging" key pair. Once you upload the encrypted tokens for decryption and use in NanoDEP we then "upstage" the staging key pair to the current key pair for use (followed by storing the DEP authentication OAuth tokens).

The upshot here is that now when one begins the DEP authentication PKI exchange (by downloading/generating the certificate) we do not invalidate the (potentially in-use) private key of the DEP name configuration. Now usually when folks renew their DEP tokens the entire process does only take a few minutes. But we wanted to prevent the case where someone starts the process by generating a certificate, but, right then, before the next steps, has a hankering for their favorite street vendor's toppings-o'-plenty piled-mile-high organic vegan hotdog that must be attended to right now (or, you know, a phone call or whatever) leaving the MDM devices hanging that depend on the correct private key.

Note that the existing, old, race condition between downloading the encrypted token from Apple and uploading the new tokens to (any) MDM. This has been an Apple limitation as the same (manual UI-driven) action that gets access to the new tokens is the same action that that invalidates the old tokens.

Note: This change introduces MySQL schema changes! Please apply the schema.00001.sql schema change to your database before using if you're using that backend.