Prototype behaviour:
* If you can't create a room in the community, say so.
* The UX for this could probably be improved, but for now the intention is to not break muscle memory by hiding the create room option.
* If you can't change settings in the community, or can't invite people, don't show those respective options.
* Breaking muscle memory here is moderately okay.
Behaviour constraints:
* If you're not in the conference, use a grey button that does nothing.
* If you're in the conference, show a button:
* If you're able to modify widgets in the room, annotate it in the context of ending the call for everyone and remove the widget. Use a confirmation dialog.
* If you're not able to modify widgets in the room, hang up.
For this we know that persistent Jitsi widgets will mean that the user is in the call, so we use that to determine if they are actually participating.
This is a step towards https://github.com/vector-im/element-web/issues/13430
Since we've stored the invite, we can send the user to it once they reload the page or revisit Element. We currently only support one invite at a time, but this should be fine for most cases.
We only do this restoration if the next screen isn't set to avoid breaking the user out of an expected flow.
As an added touch, this also ensures that the email address is pre-filled on the registration page if needed, just in case the user refreshes before getting to the submit button.
As part of new device verification, we were waiting for "cross-signing ready"
which means _both_ the public keys are trusted by this device _and_ private keys
are available. There's no guarantee that the private keys will ever arrive, so
it's too strict to wait for this as a blocking flow. This relaxes things to wait
only for the current device to trust public keys.
Fixes https://github.com/vector-im/element-web/issues/14970
Ideally this would open up the group members panel, but that's exceedingly difficult. Instead, we switch to the general chat and rename the button to be a bit more helpful.
