feat: refactor wallet pairing

[gomesalexandre]

Description

Published as alpha so ops can test this, but we'll want to wait for the actual version to be published before merging this ⚠️ blocked by shapeshift/hdwallet#656

This PR refactors the whole wallet pairing flow entirely by:

• removing the localWallet getter and setters and making it a persisted localWalletSlice instead. This was a mistake from the beginning and is the root cause of us always having reactivity and/or performance issues. local storage is not reactive, hence us trying to be reactive on localWallet values in WalletProvider was producing absurd amounts of reactivity
• ensuring event handlers are properly set for the current wallet only, and only once. We currently pass event handlers with references that may be stale because of, you guessed it, closures. Things may work the first time you connect a wallet, but switching wallets may - and will - cause a bunch of bugs
• ensuring event handlers are properly removed for the just disconnected wallet. Same issue as above, stale closure references rugged this
• ensure event handlers are properly removed on wallet switch. Even if we got lucky and events got removed on disconnect, a wallet switch would not remove them, which would produce bugs such as connecting MM, then switching to another wallet, then switching chains would make MM active again

TODOS

- [x] MM lock consistently detected
- [x] MM unlocked consistently detected
- [x] MM unlock prompt consistently showing up 
- [x] MM accounts request works when pending accounts
- [x] fix MM -> any other wallet bug where switching chains/accounts will make MM active again
- [x] stale closure variables resulting in event listeners never being removed on disconnect - fix this as this is the root cause of the above
- [x] refreshes are consistently happy and things like switching accounts, providers etc are happy

Pull Request Type

• 🐛 Bug fix (Non-breaking Change: Fixes an issue)
• 🛠️ Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
• 💅 New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #5453

Risk

Very high. This refactors wallet pairing flow entirely.

Testing

Note, before you test against develop. Note we were turbo broken for just about forever, and are having way too many event handlers / request to MetaMask. When testing against develop, you do not want to have develop and localhost open at the same time. When you test develop, you should test it in **isolation ** by ensuring you fully quit your browser, before starting to test with this PR.
Otherwise, this PR would inevitably be broken/ish (not as much as develop, but still) given the fact that there are many stale events in MM.

Alternatively, if this is too cumbersome. Test in two entirely different Chrome profiles - one with this PR, one with develop. Do not open develop in the profile use to test this, and keep things properly sandboxed to ensure sane testing.

• Test ALL wallets for pairing regressions - no need to actually broadcast Txs here

• When MM is in a locked state, clicking Connect Wallet prompts for unlock

• When MM is (either manually, or automatically on idle) locked, the locked state is reflected in the app

• When MM is unlocked, the locked state warning is gone and we properly consider MM as unlocked again

• When connecting MM originally, then another wallet (e.g WalletConnect), then switching chains or accounts in MM, MM doesn't pop up as active again

• Switching accounts or chains in MM is still properly detected when MM is connected

• When refreshing the app with MM connected, chains and account switches are still detected

• When refreshing the app, the connected wallet is still connected

Engineering

Operations

Screenshots (if applicable)

WalletConnectV2 - connect and refresh regression test against develop

Screen.Recording.2023-12-11.at.11.58.27.mov

MM - connect and refresh regression test against develop

Screen.Recording.2023-12-11.at.12.06.17.mov

MM - working locked state detection against borked develop

Screen.Recording.2023-12-11.at.12.07.15.mov

MM - working unlock prompts against borked develop

• This diff

Screen.Recording.2023-12-11.at.12.23.52.mov

• Develop

Screen.Recording.2023-12-11.at.12.25.11.mov

MM - borked event handlers resulting in MM being connected again when connecting MM -> another wallet -> switching accounts or chains in MM

• This diff

no.wtf.mov

• Develop

wtf.mov

[gomesalexandre]

Current dependencies on/for this PR:

• develop
  • PR feat: refactor wallet pairing #5817 👈

This stack of pull requests is managed by Graphite.

[woodenfurniture]

✅ All specified test cases above ok ( though only tested metamask + native)
✅ Locking then attempting to trade prompts user to unlock

✅ Upon unlocking, the trade confirmation actually appears as expected (but shocking it works so well)

✅ Connected to native, locked metamask -> switch wallet provider -> prompts user to unlock -> unlocks and connects as expected

✅ Switch wallet provider while connected to metamask -> select metamask -> stays connected
✅ Requests to switch chain with unlocked metamask working as normal

✅ Requests to switch chain with locked metamask working as normal

✅ Refreshing app opens an unlocked metamask as normal
✅ Opening new tab opens an unlocked metamask as normal
✅ Opening multiple tabs opens an unlocked metamask as normal
✅ Can have different wallets open on different tabs

[woodenfurniture]

Huge task perfectly implemented ser

[0xApotheosis]

Absolute goat PR.

Code-wise looking solid, will give a functional review before blessing with a green tick.

[0xApotheosis]

Still a package checksum issue to resolve before we can merge, but functionally this is working very well!

The Metamask hack works as expected when overriding the hidden request state, wallet switching is happy, all accounts show as expected etc, console is happy.