Handle failures when publishing cross-signing identity

[richvdh]

When first logging in on a new account, we try to publish cross-signing keys (via /device_keys/upload).

This process can fail for example, if the homeserver is configured to use SSO auth. (Publishing the public keys requires user-interactive auth, which may fail. https://github.com/matrix-org/matrix-spec-proposals/pull/3967 is an attempt to help with that, but is as yet unstandardised.)

If the process fails (either because the HS rejects it or the user gets bored of trying to do UIA and dismisses the dialog), we show an error:

After that point, the application is fully-functional, and will even allow you to set up 4S and store the private cross-signing keys in 4S. The problem is that there is no further attempt to publish the public keys, so the account is now totally broken until the user resets cross-signing.

### Tasks
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/1641
- [ ] EAR
- [ ] EIR
- [ ] https://github.com/element-hq/element-web/issues/27253
- [ ] Element X

[richvdh]

We should also finish MSC3967, which will remove many of the causes of this problem in the first place.

[andybalaam]

This is part of "WebR Force Verification" https://github.com/element-hq/crypto-internal/issues/283

[richvdh]

This is part of "WebR Force Verification"

It's not just Web R: all the other clients are affected too.

[andybalaam]

https://github.com/matrix-org/matrix-spec-proposals/pull/3967 is now merged, so we can now upload cross signing keys without interactive user authentication.

[richvdh]

matrix-org/matrix-spec-proposals#3967 is now merged, so we can now upload cross signing keys without interactive user authentication.

We can normally upload cross signing keys without interactive user authentication.

There are still cases that require UIA (notably: the user already has cross-signing keys), and there are other potential error cases. We should handle both properly.