Change Details

T3445 Create all new Cashtab wallets with only Path1899. Support legacy paths if you find them. Get rid of hardcoded paths at hardcoded keys.

T3445 Create all new Cashtab wallets with only Path1899. Support legacy paths if you find them. Get rid of hardcoded paths at hardcoded keys. Large diff. Most of the changes involve updates to mocks used by unit and integration tests. We could have split this somewhat -- migrated from balances to balanceSats in one diff, and then from hardcoded Path1899 to paths array in another -- but imo it is better to limit the number of wallet migrations overall than to do more "smaller" wallet migrations. The key changes in this diff - Update `isValidCashtabWallet` to accept new shape and reject old shape - Update `createNewCashtabWallet` to create new shape, importantly, new wallets are only created with Path1899 (not Path145 and Path245) - We support migrating Path145 and Path245 if we find a wallet with these paths. In practice, Cashtab has used Path1899 as the only change address for multiple years. Only a user with a still-in-localforage cashttab wallet that has not been used for 2 years would have money at these paths. We could consider deprecating them entirely, but, since it is not really more complicated to support multiple paths as we do it already, might as well keep doing it. Might come in useful later. Certainly makes it easier to implement HD wallets if we decide to do this. - Note the updates to migration integration tests in App.test.js. Since we are changing shape, now any wallet we find in legacy localforage keys `wallet` and `savedWallets` is expected to be invalid. - Changes to how wallets are migrated in `loadCashtabState` to account for the new `paths` key and support for legacy paths.

T3445 Create all new Cashtab wallets with only Path1899. Support legacy paths if you find them. Get rid of hardcoded paths at hardcoded keys. Large diff. Most of the changes involve updates to mocks used by unit and integration tests. We could have split this somewhat -- migrated from balances to balanceSats in one diff, and then from hardcoded Path1899 to paths array in another -- but imo it is better to limit the number of wallet migrations overall than to do more "smaller" wallet migrations. The key changes in this diff - Update `isValidCashtabWallet` to accept new shape and reject old shape - Update `createNewCashtabWallet` to create new shape, importantly, new wallets are only created with Path1899 (not Path145 and Path245) - We support migrating Path145 and Path245 if we find a wallet with these paths. In practice, Cashtab has used Path1899 as the only change address for multiple years. Only a user with a still-in-localforage cashttab wallet that has not been used for 2 years would have money at these paths. We could consider deprecating them entirely, but, since it is not really more complicated to support multiple paths as we do it already, might as well keep doing it. Might come in useful later. Certainly makes it easier to implement HD wallets if we decide to do this. - Note the updates to migration integration tests in App.test.js. Since we are changing shape, now any wallet we find in legacy localforage keys `wallet` and `savedWallets` is expected to be invalid. - Changes to how wallets are migrated in `loadCashtabState` to account for the new `paths` key and support for legacy paths.