Element-R: "Migrate to rust" labs button

[richvdh]

At some point we will need to start actively migrating people who are using EW sessions on legacy Crypto to Rust crypto.

We will need a migration process for this. To gain confidence in the migration, we will add some sort of "developer feature" where people can request a migration. Later, we will automate the migration.

Tasks

Preview Give feedback

1. Expose libolm migration code in wasm bindings matrix-org/matrix-rust-sdk-crypto-wasm#78
   +0
   
2. Add support to CryptoStores for migration to Rust Crypto matrix-org/matrix-js-sdk#3963
   A-Element-R Z-Labs +2
   
3. Rust crypto: support migration to Rust crypto matrix-org/matrix-js-sdk#3964
   A-Element-R Z-Labs +2
   
4. Element-R: add labs button to migrate to rust crypto #26772
   A-Element-R T-Enhancement Z-Labs +3
   
5. Element-R: Progress display for migration to Rust crypto #26773
   A-Element-R T-Enhancement Z-Labs +3
   
6. Element-R: migration from legacy crypto fails with Unable to load session session.sessionData.keysClaimed is undefined #26894
   A-Element-R O-Uncommon S-Major T-Defect Z-Element-R-Blocker Z-Labs +6
   
7. Element-R: migrate room list to Rust crypto #26820
   A-Element-R T-Enhancement Z-Element-R-Blocker Z-Labs +4
   

[richvdh]

UX for this will be a labs button that causes the session to be restarted when it is enabled.

We probably need some sort of modal that indicates the state of the migration.

[richvdh]

Looking at the performance of this as it stands:

On a test database containing 37 olm sessions and 4810 megolm sessions:

• 10.181s: migration start: counting the sessions to be imported
• 10.202s: start importing base data
• 10.267s: start importing olm sessions
• 10.363s: start importing megolm sessions
• 22.843s: migration complete

Obviously, that is dominated by the megolm session import, at 12.5s for 4810 sessions, or ~130ms for each batch of 50 sessions. The actual time for each batch is quite variable, but there are three stages:

• Read a batch of sessions from the legacy db. Average time: 19.0ms
• Save batch to new db. Average time: 34.1ms
• Delete the batch from the legacy db. Average time: 77.3ms.

Somewhat unexpected that deleting things from the old db is what takes the time. We could reduce it to (empirically) about 54.9ms by iterating through the store looking for rows to delete instead of using the index (which works because we know the batch will be at the "start" of the store); or we could rewrite the whole thing to store the progress made so far and delete everything on a single batch at the end. Not sure it is worthwhile though. If we need it to go faster, we can do it in the background.