chore(22552): refactor modal selector in e2e tests

[DDDDDanica]

Description

Following the suggestion divided from this thread to refactor all selectors for modal in e2e tests. They are now referred by data-testid in selector.
More specifically speaking, when the modal has been adapted to new component, a data-testid will be appended directly to <Modal > component and selected; when the component is using deprecated modal component, this data-testid will be appended to as a property passing to FadeModal component

Related issues

Fixes: #22552

Manual testing steps

1. Go to this page...

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've clearly explained what problem this PR is solving and how it is solved.
• I've linked related issues
• I've included manual testing steps
• I've included screenshots/recordings if applicable
• 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.
• I’ve properly set the pull request status:
  • In case it's not yet "ready for review", I've set it to "draft".
  • In case it's "ready for review", I've changed it from "draft" to "non-draft".

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.

[HowardBraham]

You have a few instances of ('[data-testid="account-details-modal"') with unbalanced square brackets

[DDDDDanica]

@HowardBraham Thanks a lot, that's a good catch. 👍🏻

[metamaskbot]

Builds ready [ed5ae09]

• 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
  • common: 0, 1, 2, 3, 4, 5, 6, 7
  • content-script: 0
  • contentscript: contentscript
  • disable-console: disable-console
  • inpage: inpage
  • policy-load: policy-load
  • sentry-install: sentry-install
  • ui: 0, 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9

Page Load Metrics (835 ± 26 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	93	144	119	13	6
		domContentLoaded	10	37	17	8	4
		load	708	919	835	54	26
		domInteractive	10	37	17	8	4

Bundle size diffs

• background: 0 Bytes (0.00%)
• ui: -508 Bytes (-0.01%)
• common: 0 Bytes (0.00%)

[DDDDDanica]

Similar methodology as #22672, we would wait for modal to be completed removed and then perform clicking actions.

PS: Once we completely migrated modal component, we can remove this await.

[chloeYue]

LGTM!