Fix encypt/decrypt tx queueing

[tmashuang]

Fixes #10231

Use unconfirmedTransactionsListSelector in the encypt/decrypt components to render the appropriate data to the component at the appropriate time(?).
I am still unsure how sometimes the state.confirmTransaction can we left empty sometimes on rendering the component, possibly the issue with the ConfirmTransaction componentDidUpdate constantly hitting this section.

metamask-extension/ui/app/pages/confirm-transaction/confirm-transaction.component.js

Lines 94 to 101 in 97d268c

	if (
	paramsTransactionId &&
	transactionId &&
	prevProps.paramsTransactionId !== paramsTransactionId
	) {
	clearConfirmTransaction()
	getContractMethodData(data)
	setTransactionToConfirm(paramsTransactionId)

For now this seems to be an intermediate fix.

Manual testing steps:
I've tried queueing other types of transactions in the middle and around these requests and there doesn't seem to be an issue with the order, but if anyone else can confirm much appreciated.

• Request 2 encrypt requests. Confirm/Approve both shouldn't be an issue.
  The requests can be from two different origins (edge-case check).
• Request 2 decrypt requests. Confirm/Decrypt both shouldn't be an issue. The requests can be from two different origins, and it should return the request decrypted string to the appropriate origin.

[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.

[metamaskbot]

Builds ready [d0898b9]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• code coverage: Report
• dep viz: background
• all artifacts

Page Load Metrics (678 ± 59 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	49	82	66	8	4
		domContentLoaded	423	856	676	122	59
		load	424	858	678	123	59
		domInteractive	422	856	675	122	59

[metamaskbot]

Builds ready [6772703]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• code coverage: Report
• storybook: Storybook
• all artifacts

Page Load Metrics (656 ± 60 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	44	85	63	12	6
		domContentLoaded	411	936	655	125	60
		load	412	938	656	125	60
		domInteractive	410	936	654	124	60

[darkwing]

I can confirm that this works as described! Nice @tmashuang !

[Gudahtt]

This is a weird one. I do think there is a problem in the base transaction component in the function you highlighted, but even still it looks like confirmTransaction would still be undefined at least for one render. That's enough to crash the UI.

I'm unsure what the consequences are of not using confirmTransaction here. It's a bit weird to leave that state unused here, given that there are still various hooks into it 🤔

[Gudahtt]

The base confirmation component seems to assume that each confirmation page is tolerant of confirmTransaction.txData being undefined briefly. See conf-tx.js for example, which shows a loading screen if txData or txData.msgParams is undefined: https://github.com/MetaMask/metamask-extension/blob/develop/ui/app/pages/confirm-transaction/conf-tx.js#L250

That style approach would be more in-line with how our other confirmations work. That might be better than the approach taken in this PR, which leaves a vestigial confirmTransaction state in Redux that might further confuse people in the future or lead to state inconsistencies.

That said, the whole confirm-transaction Redux slice seems entirely useless for signature and decryption requests. It looks like it was designed to hold gas-related state temporarily to allow the user to adjust gas parameters on the confirm screen, and that's about it. It doesn't really help for confirmations that don't involve gas. It would be nice at some point in the future to disassociate it entirely from these confirmations, but it's tied up in various places in the React component hierarchy right now so that wouldn't be a simple task.

[Gudahtt]

We can merge this now and create an issue to clean it up further later, since it does seem to fix the immediate problem.

Edit: I've created a ticket to track this: #10470