RustCrypto | Implement keybackup loop

[BillCarsonFr]

Implements backup loop for rust crypto.

Fixes https://github.com/vector-im/crypto-internal/issues/113

Depends on:

• Wasm bindings Expose version field of KeysBackupRequest to bindings matrix-rust-sdk-crypto-wasm#19
• Previous branch: Implement CryptoApi.checkKeyBackupAndEnable #3633

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

---

This change is marked as an internal change (Task), so will not be included in the changelog.

[t3chguy]

Looks sane

[richvdh]

I'd prefer to avoid randomness in this script, so that when we re-run it, only important things change.

[BillCarsonFr]

Added a static seed to have stable random at each generation

[richvdh]

can't we just hardcode the strings, rather than having to seed the random generator and call randbytes?

[BillCarsonFr]

Looks to me that it has best of the two words, it's stable and later on I can add more keys easilly test key upgrade and more

[richvdh]

lgtm otherwise

[richvdh]

There was some confusion about why the cypress tests didn't run on this PR. So: for the record:

1. The cypress tests only run in matrix-js-sdk as part of the merge queue (ie, after you press "Merge when ready"). This isn't terribly helpful, but the logic goes that (1) running them for every commit would be quite expensive in terms of Github Actions workers, and (2) the most likely tests to fail under Rust Crypto will be crypto-related(*), and we'll be running crypto-related cypress tests locally as part of development.

   *: recent experience shows that it's not actually the crypto test that fail, mostly because we are testing that carefully. It's all the other tests which are inherently flaky and subject to minor timing variations.

2. The cypress tests did run, and fail, as pert of the merge queue on this PR. However, they are not currently a mandatory part of the merge queue, making them effectively useless. This is probably my fault, but in any case we need to get them back to a state where they are passing more often than not before we can change it.

   Github does a terrible job of exposing the failed test run via the UI, but you can see it by clicking on the commit sha (c18d691) and then the red cross: