Change Details

Part of [ENG-9656](https://linear.app/comm/issue/ENG-9656/native-changes-for-minimal-version-of-backup) There are different ways on how this could be realized: **Option 1** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID` and `siweBackupData` 2. `getBackupUserKeys` -> to get full User Keys set, later on secrets are used to restore Backup Data and account is passed to CommCoreModule again to get signature of device list, this is the cleanest and having least complexity but we pass pickled account using JSI 3. `restoreBackupData` -> to restore User Data (the same for both Restore and Secondary Device Auth) **Option 2** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID` and `siweBackupData` 2. `getBackupUserKeys` -> to get **only** backup secrets used to Restore, having one more param which is device list to sign and return secrets along with 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 3. `restoreBackupData` -> to restore User Data (the same for both Restore and Secondary Device Auth) **Option 3** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID` and `siweBackupData` 2. `getBackupUserKeys` -> only to get the signature of the device list, downloaded backup secrets are stored somwhere 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 3. `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 implement Option 2 if someone think 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

Part of [ENG-9656](https://linear.app/comm/issue/ENG-9656/native-changes-for-minimal-version-of-backup) There are different ways on how this could be realized: **Option 1** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID`, and `siweBackupData` 2. `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 3. `restoreBackupData` -> to restore User Data (the same for both Restore and Secondary Device Auth) **Option 2** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID`, and `siweBackupData` 2. `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 3. `restoreBackupData` -> to restore User Data (the same for both Restore and Secondary Device Auth) **Option 3** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID`, and `siweBackupData` 2. `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 3. `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

Part of [ENG-9656](https://linear.app/comm/issue/ENG-9656/native-changes-for-minimal-version-of-backup) There are different ways on how this could be realized: **Option 1** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID`, and `siweBackupData` 2. `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 havinghas the least complexity but we passtransfer pickled account using JSI 3. `restoreBackupData` -> to restore User Data (the same for both Restore and Secondary Device Auth) **Option 2** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID`, and `siweBackupData` 2. `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 3. `restoreBackupData` -> to restore User Data (the same for both Restore and Secondary Device Auth) **Option 3** 1. `retrieveLatestBackupInfo` -> to get `backupID`, `userID`, and `siweBackupData` 2. `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 3. `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