Add Key rotation endpoints

Closes #65 (closed)

This MR introduces key rotation logic for the keys that create open invitation tokens, invitation credentials, and Lox credentials.

Unfortunately since it's not possible to make an HTTP request directly from the wasm, there isn't a good way to automate the credential update process. The best we can do is call update_cred directly from the check_lox_pubkeys_update or check_invitation_pubkeys_update function so that if there is a key update, it prepares the request automatically. If a key rotation is indicated, the resulting request still needs to be sent to the distributor and the result of that request handled with the handle_update_cred function, so this will require changes to the Tor browser integration but I think that would be required anyway.

I would recommend that a calls to check_lox_pubkeys_updateand check_invitation_pubkeys_update should be made at a regular interval, maybe about once/week (and only if a user has an invitation for the latter case) or so and if it returns a {true, update_cred_request}, then the work flow is:

• replace the old lox_pub pubkey with the new one
• send the update_cred_request or update_invite_request to the lox authority's updatecred or updateinvite endpoint
• call the handle_update_cred or handle_update_invite function with the response from that request

We want to avoid users requesting to update their credential immediately prior to another lox endpoint request so that the two actions can not be linked as it can leak information about the updated credential. To illustrate this, if the number of requests per day is relatively low and the lox pubkey was rotated more than 50 days ago, a request for a credential update immediately prior to an issue_invite request for example, would allow the LA to know that the user requesting the invitation hasn't engaged with the lox authority for 50 days, which would give an indication of their trust level and the time the credential was last issued. If the credential can be updated closer to the time of the key change, it reduces the likelihood of leaking extra information.

I think the case of open invitations is the exception here. A user presents the invitation token in plain text anyway, so I think we can just add on to the existing protocol to check if it was issued with an old key.

Still TODO:

• how often do we need to rotate keys? Can this be automated?