Add support for device dehydration v2

[uhoreg]

Rehydrates/dehydrates device if dehydration is enabled in .well-known file (or if there is a dehydration key in SSSS). (Currently, js-sdk only supports dehydration when using Rust crypto.)

Dehydrated devices are hidden or displayed specially when they are cross-signed, and if there is only one. Otherwise, they are displayed as normal devices.

Checklist

• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• Sign-off given on the changes (see CONTRIBUTING.md).

[t3chguy]

Looks like SonarCloud doesn't consider the playwright tests?

Correct, because even just launching the app would hit like 30% overall test coverage without any useful assertions

[richvdh]

Suggested change

	* Dehydration can only be enabled if encryption is available, and the crypto
	* backend supports dehydration.
	* Note that this doesn't necessarily mean that device dehydration has been initialised
	* (yet) on this client; rather, it means that the server supports it, the crypto backend
	* supports it, and the application configuration suggests that it *should* be
	* initialised on this device.

[richvdh]

Ok. I suggest you make an issue about it if you don't expect to have it done in very short order.

[richvdh]

As @t3chguy implies: I'm afraid you'll need to write jest tests to get the coverage up. Hopefully it should be pretty easy.

[uhoreg]

Yup, I'll try to write some stuff to make SonarCloud happy

[richvdh]

@uhoreg Did you get a chance to make an issue?

[richvdh]

LGTM. The tests look very comprehensive!

[t3chguy]

This seems to have bypassed labs but relies on experimental MSC implementations, this is quite unexpected

[uhoreg]

This seems to have bypassed labs but relies on experimental MSC implementations, this is quite unexpected

It has to be enabled on the server by editing the homeserver.yaml, and needs something added to the server's .well-known file, so I didn't think it needed any more configuration to turn it on. Also, a bunch of it runs on login, before the user is able to enable the labs flag.

[t3chguy]

before the user is able to enable the labs flag.

Sure, that's why we support setting labs flags in config.json - normally the product policy is to not release things relying on unstable APIs without product sign off