[cherry pick] Fix bugs related to queued requests

[Gudahtt]

This is a cherry-pick of #28090 for v12.6.0. Original description:

Description

Bumps @metamask/queued-request-controller to fix queueing issue with Chain Permission wallet_switchEthereumChain and wallet_addEthereumChain when switching to a previously permitted chain and with wallet_addEthereumChain not being enqueued when it still should be.

Related issues

Related: MetaMask/core#4846
Fixes: #28101
Fixes: #27977
Fixes: #28102

Manual testing steps

The easiest way to test this would be a combination of using the test dapp and the following request to switch chains

await window.ethereum.request({
 "method": "wallet_switchEthereumChain",
 "params": [
  {
    chainId: "0x1"
  }
],
});

The behaviors you should see include:
One dapp:

• On a dapp permissioned for chain A and B, on chain A, queue up several send transactions, then use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected.
• On a dapp permissioned for chain A and B, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the dapp, and all subsequent approvals cleared/rejected automatically.
• On a dapp permissioned for ONLY chain A, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals.
• On a dapp permissioned for ONLY chain A, on chain A, wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals.

Two dapps:

• On a dapp permissioned for chain A, on chain A, queue up several send transactions, On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected.
• On a dapp permissioned for chain A and B, on chain A, queue up one send transaction. On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. Then on the first dapp queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the second dapp, and then you should still be prompted with the subsequent approvals for the first dapp.
• One one dapp, start a wallet_addEthereumChain for a chain that does not exist in the wallet and leave the approval alone. On a different dapp, do the same thing. Only the request from the first dapp should be accessible (i.e. no scrubbing between both of them). After rejecting the first request, the second request should then appear (which will look exactly the same of course). Wallet should not lock up if you repeat this and accept either of the requests

Screenshots/Recordings

Before

After

Screen.Recording.2024-10-24.at.1.57.19.PM.mov

Screen.Recording.2024-10-30.at.8.44.54.AM.mov

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/@metamask/base-controller@7.0.2	None	+1	1.06 MB	metamaskbot
npm/@metamask/controller-utils@11.4.2	network	0	264 kB	metamaskbot
npm/@metamask/queued-request-controller@7.0.0	None	+2	348 kB

🚮 Removed packages: npm/@metamask/base-controller@7.0.1, npm/@metamask/queued-request-controller@2.0.0

View full report↗︎

[Gudahtt]

@metamaskbot update-policies

[metamaskbot]

Policies updated.
👀 Please review the diff for suspicious new powers.

🧠 Learn how: https://lavamoat.github.io/guides/policy-diff/#what-to-look-for-when-reviewing-a-policy-diff

[metamaskbot]

Builds ready [bd86740]

• builds: chrome, firefox
• builds (beta): chrome
• builds (flask): chrome, firefox
• builds (MMI): chrome, firefox
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Background Module Init Stats
• mv3: UI Init Stats
• mv3: Module Load Stats
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• code coverage: Report
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6
  • common: 0, 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9
  • content-script: 0
  • offscreen: 0
  • ui: 0, 1, 10, 11, 12, 2, 3, 4, 5, 6, 7, 8, 9

Page Load Metrics (1862 ± 89 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	1684	2365	1866	192	92
		domContentLoaded	1672	2334	1821	170	82
		load	1682	2344	1862	186	89
		domInteractive	16	151	51	38	18
		backgroundConnect	10	212	46	50	24
		firstReactRender	48	309	117	65	31
		getState	5	190	31	46	22
		initialActions	0	1	0	0	0
		loadScripts	1184	1828	1347	146	70
		setupStore	11	206	41	45	22
		uiStartup	1887	2855	2142	293	141

Bundle size diffs [🚀 Bundle size reduced!]

• background: -76.66 KiB (-1.54%)
• ui: 1.28 KiB (0.02%)
• common: 75.11 KiB (0.95%)

[metamaskbot]

No release label on PR. Adding release label release-12.6.0 on PR, as PR was cherry-picked in branch 12.6.0.