E2EE sending is slowed down badly by devices on distant/slow servers.

### Steps to reproduce

1. Send a message in a new megolm session to an E2EE room with lots of servers
2. Discover that the process of setting up Olm sessions and claiming keys on servers in the room which are distant or struggling can take a long time, slowing down message send for *all* users in the room, even if they are fast local users.
3. Therefore, bad servers have the ability to DoS message sending in E2EE rooms.
4. The problem is even worse if you retry setting up Olm to a dead server (or OTK-expired user) every time you try to send a new message in the room: https://github.com/vector-im/element-web/issues/26375

### Outcome

#### What did you expect?

Message sending to healthy devices shouldn't be blocked behind slow sending to unhealthy devices.

Are we sure that we're doing the right thing by only showing a message as sent once the full olm setup + megolm share process has completed?

* Pros:
* By the time the message is sent, the user knows their client has encrypted and sent it to everyone it could successfully contact.
* Cons:
* This could take ages, as servers which are slow/down/distant will take a long time to respond to /key/claims - and the user may care more about sending the message to 'healthy' devices than blocking the healthy devices on trying to contact unhealthy ones.

I wonder whether a better UX would be to track the health of devices (e.g. ones where in the past we've been able to set up Olm in less than a second) and show messages as sent (and send the m.room.encrypted event) once we've shared keys to those healthy devices. We would then try to share with the unhealthy devices slowly in the background. This could be shown to the user as an additional send state per message, or a global "syncing keys" state for the client as a whole.

As a result, the app would feel faster to send messages, healthy clients would get them sooner, but on the other hand unhealthy clients might see UTDs for longer while waiting for the keys to eventually get sent.

#### What happened instead?

Minor DoS vector, and slow E2EE.

### Operating system

_No response_

### Application version

_No response_

### How did you install the app?

_No response_

### Homeserver

_No response_

### Will you send logs?

No