Add support for device dehydration v2 (Element R)

[uhoreg]

No description provided.

[richvdh]

LGTM other than a few suggestions which may or may not be helpful

[richvdh]

I'm a bit concerned that the API is moderately complicated, and that we're expecting each application to know when to call isDehydrationSupported, rehydrateDeviceIfAvailable, scheduleDeviceDehydration etc.

I've been thinking about this a bit more, and it's continuing to nag at me.

In particular: we already have a bit of a mess with APIs like isSecretStorageReady, bootstrapSecretStorage, isCrossSigningReady, bootstrapCrossSigning: they have unclear semantics, and it's unclear when the application is meant to call them, and in what order. This is mostly because they were defined back in 2018 when we thought it was "obvious" what they did and when you should call them, but then they evolved and now it's really unclear.

I'm really worried that we're compounding this situation by adding a bunch more methods that the application is supposed to call at some ill-defined time during startup.

For example:

• Is it necessary that secret storage is correctly configured before calling the dehydration methods? What is the expected behaviour of these methods if it is not configured?
• We are likely to see every possible combination of (new/existing session), (account with/without secret storage), (device with/without cached secret storage key), (account with/without cross-signing), (device verified/not verified), (device with/without access to master cross-signing keys). I'm not sure which, if any, of those are relevant, but I do feel like we should make any constraints absolutely explicit.

The React SDK isn't doing much with scheduleDeviceDehydration currently -- it never uses the delay parameter. This will come in a future iteration, where the application needs to store the time when a dehydrated device was last created, so that when you re-start, it will be able to re-schedule dehydration. I had considered making that part of the js-sdk, but the js-sdk doesn't seem to have a good place to store things like that. (In the past, I would have thrown it in the crypto store, but we don't have access to that any more, and the rest of the SDK doesn't seem to have a good place to easily persist random bits of information.)

A couple of things on this:

• The MatrixClient is initialised with a Store. It's typically used for caching the last /sync response, but we could conceivably extend it to store this sort of information. The thing about Store is that it is a cache: if it is blown away, then we can resync from the server without loss of information. But that might be ok here?
• If it's important, we can and should use the rust-side store for this sort of information. It probably means pushing more of this functionality down into the Rust layer, but that may not be a bad thing?

[richvdh]

Suggested change

	* If the delay is omitted or 0, this function's promise will resolve after
	* the first dehydrated device is created.
	* If the delay is omitted or 0, this function's promise will resolve after
	* the first dehydrated device is created. Otherwise, it resolves immediately.

[uhoreg]

The React SDK isn't doing much with scheduleDeviceDehydration currently -- it never uses the delay parameter. This will come in a future iteration, where the application needs to store the time when a dehydrated device was last created, so that when you re-start, it will be able to re-schedule dehydration. I had considered making that part of the js-sdk, but the js-sdk doesn't seem to have a good place to store things like that. (In the past, I would have thrown it in the crypto store, but we don't have access to that any more, and the rest of the SDK doesn't seem to have a good place to easily persist random bits of information.)

A couple of things on this:

* The MatrixClient is initialised with a `Store`. It's typically used for caching the last `/sync` response, but we could conceivably extend it to store this sort of information. The thing about `Store` is that it is a _cache_: if it is blown away, then we can resync from the server without loss of information. But that might be ok here?

* If it's important, we can and should use the rust-side store for this sort of information. It probably means pushing more of this functionality down into the Rust layer, but that may not be a bad thing?

Having thought a bit more about this, I don't think it's critical that we need to store that information. If we replace the dehydrated device early, nothing bad will happen, so on restart, we can just create a new dehydrated device right away, and continue from there with the normal scheduling. So I can change the schedule... function to always create a new dehydrated device right away. I'll also give it a default period.

Regarding the larger API concerns, I'll give it some thought, about whether I can throw things into bootstrapCrossSigning

[uhoreg]

I've implemented a simpler API. Now, clients just need to check if dehydration is available, and then tell it to start dehydration, and it'll do everything necessary. Clients can re-start dehydration if it, e.g. needs to create a new dehydration key when it resets secret storage.

[richvdh]

Excellent, this seems better! Still a couple of concerns.

[richvdh]

LGTM!