Prototype encrypted room history sharing

[andybalaam]

Prototype to flesh out ideas for #39

The plan is to implement in matrix-sdk-crypto + multiverse (or switch to EW if that is a problem).

For the prototype we will have these caveats:

• save a key bundle into a single encrypted media file
• ignore the need to delete the file after use.
• initially, ignore races e.g. new messages arriving while we are preparing

The prototype will help us answer these questions:

• Does the idea basically work?
• Does the invitation event need to change?
• What if new messages are sent after creating the media file?
• Are there other races?
• Is it fast enough? Do I get the keys I care about in a reasonable time?
• We should revisit our list of caveats with MSC3061 and check that they are addressed

### Tasks
- [ ] https://github.com/element-hq/element-meta/issues/2688
- [ ] https://github.com/element-hq/element-meta/issues/2689
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4504
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4505
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4508
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4509
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4510
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4511
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4512
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4513
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4514
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/4926
- [ ] Test out the prototype, and check that it addresses the MSC3061 caveats

[richvdh]

For want of a better place, I'm going to start some notes here on things that I've come across while doing the prototyping work that we should think about before productionising it:

• What should we do about devices belonging to the invitee that are not correctly cross-signed, or that we cannot establish an Olm session with? Ideally we would send an m.room_key.withheld, but that requires a single session ID. We don't really want to be sending one withheld message per session. We probably need some other out-of-band mechansm.
• Similarly, we previously talked about sending withheld messages for sessions that were not marked as shareable. This hasn't been done as part of the prototype.
• What should happen about third-party invites? It's highly problematic because, at the time we send the invite, the target user may not even have a Matrix account, far less a Matrix device capable of secure E2EE.
• The prototype implementation does not include any support for indexeddb databases, which would be needed for support on element-web.
• Suppose we (say) get the megolm session at index 0 via history sharing, then later get the session at index 1 directly. We'll probably want to merge the sessions (since we can be sure of the owner in that case); otherwise we might get a few extra "as presented by <Bob>" messages where we could do better.