This does a number of things (sorry):
* Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593)
* Sets up the stack for a whole new room list store, and later components for usage.
* Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled
* Demonstrates a possible structure for algorithms
Like a5f3318f3b, this proves that the new dispatcher conversion works for fire-and-forget style dispatches too. This is another obvious-if-broken and generally safe conversion to make.
Other actions which can be dispatched this way have been excluded for reasons mentioned in the Action enum's comments.
This is a relatively obvious dispatch action that doesn't require a lot of complicated type definitions, so should be a good candidate to prove the thing works. If for some reason the thing stops working, we've done something wrong.
This also adds a bit of generic types to the dispatch call so we don't confuse the tsx parser by using `dis.dispatch(<ViewUserPayload>{...})` as it thinks that's supposed to be a component. We still get type safety, and the thing remains happy with the generics approach.
Fixes https://github.com/vector-im/riot-web/issues/13645
Every time the checkbox value changes we acquire a new session now. This avoids us asking the server to change its direction partway through the request.
This causes a bit of UI jerk as the dialog goes from auth -> loading -> auth, however it's better than the alternative of reworking the entire UIA structure to support the `authData` dict changing. Originally this commit consisted of a `disabled` flag on the `InteractiveAuth` component which carried through to the stage's component, however it turns out that stack doesn't respect changes to the `authData` prop, which means the session ID we eventually send down is wrong (`erase: false` instead of the one with `erase: true`). Therefore, we do some logic to ensure we remount `InteractiveAuth` completely.
Further work in this area is described in https://github.com/vector-im/riot-web/issues/13646
Rageshakes from the wild indicate that device was null here which
implies that we somehow did not know about the device when verifiying
it? Log and null-check to avoid a soft crash.
We prompt to restore the key backup when bootstrapping if it's not
trusted, but the 'set up new recovery options' in this dialog just
sets up a new key backup which just goes back to trying to access
SSSS if cross-signing is enabled. This makes it reset the SSSS
passphase instead.
Fixes https://github.com/vector-im/riot-web/issues/13578
