Support updating recovery key after account creation

[AaronGoldman]

Is your feature request related to a problem? Please describe.

Currently a user can send a recoveryKey when the user first calls packages/pds/src/api/com/atproto/server/createAccount.ts.

They can update their Handle with packages/pds/src/api/com/atproto/identity/updateHandle.ts.

Describe the solution you'd like

We should add an endpoint to update the recoveryKey packages/pds/src/api/com/atproto/identity/updateRecoveryKey.ts reading the recoveryKey from input.body.recoveryKey

e.g.

POST https://bsky.social/xrpc/com.atproto.identity.updateRecoveryKey
{
    "recoveryKey": "did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGb"
}

Describe alternatives you've considered The UI could force the user to generate a recoveryKey to be able to call createAccount and the user could use this recoveryKey to update their own DID Document.

Additional context This is needed for a user that did not set a recoveryKey when they called createAccount to recover a state of being able to migrate PDSs without the permission of their current PDS operator.

The UI should let the user enter their own did:key but if the user choses to generate one the seed words that hash to the Secret key should not be sent to the server the did:key should be generated locally. https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

[yamarten]

I also want to be able to register the recovery key later, but I think this API needs several discussions before implementation.

• This depends greatly on the specifications of did:plc. did:web will simply be an error because it does not need a recovery key, but when the future DID method has a similar function, it may be important to compatibility with this API. createAccount also has similar problem.
• In did:plc, the key should always be added, not update. Disabling existing rotation keys may cause extra checks and problems, but users can avoid them by directly disabling after addition.
• In did:plc, it is necessary to consider the priority of the key. User recovery key has usually the highest priority, but if the API allows to add or update the highest priority key, the PDS password leak may develop into the DID hijack.