fix: wallet state corruption round 4

[woodenfurniture]

Description

Patch for state corruption in wallet provider when user backs out of switching wallet. See #7904 for context.

The fix here is a patch to prevent corrupt state by preventing "back-out" of native connect into corrupt state by forcing the previous wallet to first disconnect before the password prompt is displayed.

Previous issue in simplified terms:

1. User is connected to native wallet
2. User clicks "switch wallet"
3. User clicks different native wallet and is presented with password prompt
4. WalletProvider updates the deviceId with the new wallet device ID
5. User exits the password prompt without entering the password
6. WalletProvider now has the wrong deviceId until they reconnect the wallet

This PR:

1. User is connected to native wallet
2. User clicks "switch wallet"
3. User clicks different native wallet and is presented with password prompt
4. Both the WalletProvider deviceId and the redux wallet ID are cleared, wallet is disconnected
5. User exits the password prompt without entering the password
6. User is in a disconnected state without mismatch of wallet device IDs

See below jam exaplaining in more detail.

Issue (if applicable)

closes #7904

Risk

High Risk PRs Require 2 approvals

High risk because it modifies WalletProvider and could theoretically result in inability to open a wallet.

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

All wallets, especially native.

Testing

Thoroughly test opening/closing/switching wallets, with more emphasis on native wallet.
Sanity check signin, broadcasting, trading etc is not somehow unexpectedly broken.

Engineering

Operations

• 🏁 My feature is behind a flag and doesn't require operations testing (yet)

Screenshots (if applicable)

Have a watch of my home movie explaining everything (audio on)
https://jam.dev/c/22a2572a-aeb6-4a82-a6c2-bd79bac3079d

[gomesalexandre]

Diff-wise looks excellent.
A few comments mostly re: types and cleanup, but shouldn't really change anything at runtime (the KK event listeners would just be EventEmitter spew rather than an actual bug, assuming we ever end up there).

Runtime pass incoming, stay tuned 🎸

[gomesalexandre]

Tested localy, purposedly starting from a non nuked cache with these guys cached

• two native wallet
• two MIPD wallets
• Ledger
• KK

Wallet connection flow - right accounts derived and no race shenanigns

Native ✅

• Native is happy e2e: unlock, refresh and unlock, disconnect/reconnect, keystore import ✅

https://jam.dev/c/3a4e5f08-8f0b-4e04-943b-f04beb3f2974

Ledger ✅

https://jam.dev/c/9e00c010-d8ca-4738-bce1-a04e3a54d8ad

KeepKey ✅

https://jam.dev/c/c2825d4c-12dc-4e47-8720-1c09a1b8c728

MIPD Wallets ✅

https://jam.dev/c/3db330fc-71b8-4d09-af17-ae2089608d83

Phantom ✅

https://jam.dev/c/0bb2142a-7fab-4d48-83c5-34797c68ae2b

Signing

Native ✅

https://jam.dev/c/c29ed56d-1df7-44fc-98ff-7bad41b18294

MIPD ✅

https://jam.dev/c/c951c98e-ab0b-4326-8a38-ea420f7c787e

KK ✅

https://jam.dev/c/c7be8103-d524-406b-adb8-a90856481e30

Ledger ✅

https://jam.dev/c/89b5c194-f71b-49a6-ad3f-e149ba213150

Noted one smolish bug however, which I can also repro in develop, not introduced by this diff. Captured in #8535.

• When connecting a mipd wallet with a given ENS associated to it, then connecting to Ledger (to another EVM address set, without ENS associated to it), stale ENS is displayed

• this diff: https://jam.dev/c/d9a18722-74cb-41bc-8f38-aa8daa917d7f

• develop: https://jam.dev/c/4635c6ea-dc26-4222-bec6-8c10f62345e1

[0xApotheosis]

Looking solid - tried every combination of switching/disconnecting wallets - all worked well, signing still happy.