feat: Update Keychain for new modified-zip32

[jurevans]

Resolves #1611

• Modified zip32 is handled with a constant BIP44 path of m/44'/877'/0'/0'/2147483647'
• Update SDK tests for shielded accounts
• Add field to storage (shielded accounts only) indicating modified zip32 path
  • This should be modifiedZip32Path: "m/44'/877'/0'/0'/2147483647'"
  • This should only apply to shielded accounts derived from a mnemonic! Imported private keys (seed for zip32) are already derived, therefore, we can't make any assumptions as to how it was derived, so leave this field out!)
• Accounts (mnemonic-based, shielded-only) without this field should display a warning to re-import
• Add Zip32 form in Advanced (will attach designs soon)
• Handle "Account Already Imported" better
  • Say you specify custom paths (BIP44 and ZIP32), if the BIP44 account hasn't already been used, but the ZIP32 has, you get an error on import
  • When this happens, the Transparent account exists and is set as the active account, but, you can't see it in the overview :( This needs to be fixed!
• Only return shielded keys to Namadillo if they are not outdated!
• Also, if you import accounts but get an error on the Shielded keys because that address is already used, you will still see the transparent account in the extension (was hidden/filtered out before) - This relates to a bug reported by a user and is fixed here. Transparent Namada keys without shielded keys should display in both Extension & Namadillo.

Testing

New functionality:

• Set some accounts up in an extension based on main (running extension locally so its store is preserved when switching branches)
• Switch to this branch, reload extension in Manage Extensions - When launching the account overview, you should see a warning to update your accounts
• Re-import one of the accounts, and that account should no longer have the warning!
• Also, can test custom derivation paths
  • You must specify a custom path for Zip32 if you have already imported the default path (should see an error that the account already exists)

The most critical thing to confirm is:

• The same mnemonic & path should produce the same keys in:
  • Keychain extension (this branch)
  • CLI wallet (must be on namada version v1.1.1+!)
    • Check viewing keys, as CLI payment addresses are diversified - Keychain currently uses default_address off of the viewing key (will introduce additional payment addresses after this release!)

      # Derive some shielded keys
      namadaw derive --shielded --hd-path "m/32'/877'/0'" --alias "shielded /0"
      namadaw derive --shielded --hd-path "m/32'/877'/1'" --alias "shielded /1"
      
      # This will display viewing key: Ensure this matches the same mnemonic/zip32 path in Extension!
      namadaw list

  • Ledger HW Wallet (version 3.0.0+)
    • Verify viewing key
    • NOTE This is trickier to test, but I can check against Ledger in Ledger MASP Integration #1575

Notes

New shielded accounts generated from a mnemonic (not private key import) now look like this in storage:

{
    "id": "0459542.....",
    "address": "znam1...",
    "alias": "Tester",
    "parentId": "485057eb-...",
    "path": {
        "account": 0
    },
    "type": "shielded-keys",
    "modifiedZip32Path": "m/44'/877'/0'/0'/2147483647'",
    "owner": "zvknam1....",
    "pseudoExtendedKey": "039cd768...",
    "source": "imported",
    "timestamp": 0
}

This indicates:

1. That is was derived using modified-zip32
2. How exactly the seed for the zip32 derivation was derived (this path is a constant)
3. The path components of the zip32 derivation itself (account = 0 - user can now change this)

So, with this we can check whether or not the user's shielded keys are supported.

[jurevans]

Just a note about this change: So we had a deriveAccount method, which would alternatively call deriveTransparentAccount or deriveShieldedAccount, but it was never used for transparent, so I consolidated it into one function, deriveShieldedAccount

[jurevans]

If/when we allow deriving only Transparent, we can add a specific call for it at that time

[euharrison]

Nice! I builded the extension locally and can observe the new shielded address and the new viewing key, but transparent address was preserved

[mateuszjasiuk]

Tested and LGTM! :) So if we have old account the MASP tab looks like this:

I assume this is fine, right?

[jurevans]

I assume this is fine, right?

@mateuszjasiuk I think this is fine, things like sync won't work because this no longer returns shielded accounts (if they're outdated). But I also do think we need to communicate that this will happen if user has outdated accounts. Otherwise we'd need to make more changes to Namadillo