Add restoreKeybackup to CryptoApi.

[florianduros]

Checklist

• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• Sign-off given on the changes (see CONTRIBUTING.md).

Task element-hq/element-web#26922

The goal is to simplify the restoreKeyBackup api and move it out of the MatrixClient to the CryptoApi.

• Added two methods to CryptoApi
  • restoreKeyBackup
    • if a recovery key is provided, we use it otherwise we try to getting form our local cache or from the secret storage.
    • In RestoreKeyBackupDialog we never target a specific session or room when calling the restoreKeyBackup* consequently I get rid of the targetRoomId and targetSessionId.
    • Also IKeyBackupRestoreOpts.cacheCompleteCallback is not used in RestoreKeyBackupDialog, I removed also this parameter.
    • Instead of having the keyBackupInfo as a parameter, we directly retrieve it internally.
  • restoreKeyBackupWithPassphrase which is deprecated because deriving a key backup from the passphrase is not in the spec.
  • Moved the key backup specific code into the RustBackupManager.
• Deprecate the restoreKeyBackup* in MatrixClient

[richvdh]

• Added two methods to CryptoApi

  • restoreKeyBackup

    • I went with the following logic to avoid to have to much public methods to restore a key backup: If a recovery key is provided, we use it otherwise we try to getting form our local cache or from the secret storage.

Sounds sensible.

* In [`RestoreKeyBackupDialog.`](https://github.com/element-hq/element-web/blob/develop/src/components/views/dialogs/security/RestoreKeyBackupDialog.tsx?rgh-link-date=2024-10-29T09%3A43%3A16Z) we never target a specific session or room when calling the `restoreKeyBackup*` consequently I get rid of the `targetRoomId` and `targetSessionId`. However since the `js-sdk` is used also by other clients, should we keep this parameters ?

No. There is no real reason for applications to be restoring keys at the room level (and certainly not at the session level). The crypto stack will fetch keys on demand. Let's drop support for those parameters.

• restoreKeyBackupWithPassphrase which is deprecated because deriving a key backup from the passphrase is not in the spec. However we are still deriving in EW so we have also to support the restoration. (But maybe we should not deprecated it ? Should we only deprecate the keybackup creation from the passphrase and not the backup restoration)

Yeah, I think that it makes sense to mark restoreKeyBackupWithPassphrase as deprecated.

[richvdh]

This looks like a very sensible start. Obviously, please make sure that any new public types and methods are clearly documented, but I think you know that.

[richvdh]

LGTM otherwise