Part of ENG-9656
There are different ways on how this could be realized:
Option 1
- retrieveLatestBackupInfo -> to get backupID, userID, and siweBackupData
- getBackupUserKeys -> to get full User Keys set, later on, secrets are used to restore Backup Data and the account is passed to CommCoreModule again to get the signature of the device list, this is the cleanest and has the least complexity but we transfer pickled account using JSI
- restoreBackupData -> to restore User Data (the same for both Restore and Secondary Device Auth)
Option 2
- retrieveLatestBackupInfo -> to get backupID, userID, and siweBackupData
- getBackupUserKeys -> to get only backup secrets used to Restore, having one more param which is the device list to sign and return secrets along with the signed device list, it's similar in terms of readability to Option 1, avoids transferring pickled account using JSI but it's a lot more complex on the C++/Rust level
- restoreBackupData -> to restore User Data (the same for both Restore and Secondary Device Auth)
Option 3
- retrieveLatestBackupInfo -> to get backupID, userID, and siweBackupData
- getBackupUserKeys -> only to get the signature of the device list, downloaded backup secrets are stored somewhere in the native code (not sure where) and can be later used for restoring. Really complex but we don't pass any data via JSI
- restoreBackupData -> to restore User Data, but two different implementations: for Secondary Device secrets are passed as params (received from the primary), on restore those are stored somewhere in the native code
I implemented Option 1, but I am open to implementing Option 2 if someone thinks this is better.
Note that retrieveLatestBackupInfo and getBackupUserKeys ale always two separate calls - it's from the nature of the backup, which was designed to "stream" data directly from the Blob service in case of User Keys and User Data, so adding userID and siweBackupData there is not possible.
Depends on D14004