feat/1295 - Update Namada Keychain integration

[jurevans]

resolves #1295
resolves #1270

• Clean up Signer class (keep only signing-related functions, similar to Keplr interface)
• Update namada.connect(), namada.disconnect() to accept optional chainId - this will be used to set approved signing chain, but may not be added in this PR (depending on time) but it will be good to have to be backward compatible
• Namadillo should provide current chainId to extension on connect, is connected, and disconnect
• Remove dependency on @namada/integrations - this may take a few iterations, but once Namadillo is completely updated, we can probably just remove this package
• Fix Namadillo issues with detection (to trigger this behavior reliably, change something in Settings)
• Update Faucet app to account for any API changes (will fix Docker build)
• Approve Connection should also approve chainId for signing (now that we have the chainId - may need to adjust a bit so that pointing to a new indexer (if it has a different chainId) triggers an approval or Connect button
• Remove deprecated viewing keys function in balance/atoms.ts
• Fix tests
  • TODO: When we make chainId required for approvals, update tests to reflect this. For now, it should work the old way as well, only it won't update the value in Network

Notes

• FYI, I had originally implemented a wallet manager for Namada Keychain, but I think it should only share a part of that interface since it wouldn't ever work well with the Keplr wallet manager, so I'm making a separate hook specifically for Namada Keychain, as our current integration is already separate

TESTING

NOTE In general, we just want to make sure any extension functionality works as expected, and if the extension is installed, you should never see the Download button. The following is how I tested this:

• From this branch, load Dry-Run settings and connect extension (you should be prompted to approve domain & enable signing for chainId:

  https://indexer.namada-dryrun.tududes.com
  https://rpc.namada-dryrun.tududes.com
  https://masp.namada-dryrun.tududes.com

• Check Network in extension, this should be set to the current chain ID
• Load a different indexer (Housefire) in Namadillo: https://indexer.knowable.run - you should be prompted to approve once the new chain ID is set
• Check Network in extension, this should be set to the new chain ID. Also, you can check this in the console with: await namada.getChain()
• Test sign Tx and sign-arbitrary
• Test switching users and Disconnect
• Run await namada.accounts() to see cleaned up data
• You must now use const signer = namada.getSigner() instead of namada.signer() if you want to use the Signer API (same results as the namada.signTx() calls, only the usage is different as before).
• Also, test for any cases where Download is displayed when the extension is installed - this should be fixed now!
• In Chrome, launch a private tab to see the Download state (CMD+Shift+N)

[euharrison]

Do you think we should render the chain id on the "Connected Sites" page?

And disconnect with the chain id as well?

[euharrison]

I'm wondering if this field should be mandatory 🤔

[jurevans]

I was hoping to make it optional while we transition to the new Namadillo, however, since the Signer class changed, it breaks the old Namadillo anyways :D I can easily make it required, will just need to update the approval tests!

[jurevans]

@euharrison So, to get this to work as a required param, we'll need to update @namada/integrations (and the Faucet app) which I was hoping to avoid in this PR. There is the case of the Faucet where a chain ID isn't needed, as all it does is load accounts, so I'm wondering how we should handle that? I think for now, it shouldn't hurt to leave it as optional, and only set the Network setting if it is provided.

[euharrison]

friendly remember to merge from main before merging :)

[jurevans]

I explicitly took this out since that interface is no longer valid (no owner exists in the extension). Are you saying it should be kept?

[jurevans]

I did rebase it to main

[jurevans]

ah, I see the new conflicts. I promise I won't merge with conflicts :D

[euharrison]

@jurevans unfortunately we still need to preserve this. Because we could have someone that do not updated the extension, but is already using the new Namadillo, then we still need to provide some support for them

[jurevans]

@euharrison I was thinking about this, and to keep that function, we'll also need to keep owner in Extension, which means I need to revert some things in extension, right? As soon as we publish the Chrome extension, it should auto-upgrade on users machines, so we can assume that they'll be on the latest, and I plan to announce this to users on Discord who may be using the test build I provided.

[jurevans]

@euharrison just FYI, there are some other breaking changes if there is a mismatch between this Namadillo & extension, so if our plan is to support previous and current version, there will be quite a bit of handling needed, and I personally think it would be best to move everything to the latest, inform people to update their extension (it should be handled automatically for Chrome Store users), and ensure we get Namadillo published on Dry-Run & Housefire. Do you think that would be too problematic?

[jurevans]

Do you think we should render the chain id on the "Connected Sites" page?

And disconnect with the chain id as well?

@euharrison thanks for taking a look! Currently, chainId isn't tied to any domain. I have another PR that establishes a hierarchy of permissions here: #1142 - In that PR, chainId actually does something on those views, but in this PR, disconnect will simply clear the approved domain. I think for this PR chainId should not be used in those calls (but we can make it required so that it's more future-proof), then it will be available when permissions can be set by domain + by chain ID. Does that make sense?