feat: account sync - primary SRP filtering, bulk accounts creation and synced accounts limit removal #30317

[mathieuartu]

Description

This PR bumps:

• @metamask/profile-sync-controller from ^7.0.1 to ^8.1.0

This package bump alongside the files changed will ensure that:

• Account syncing will only "care" about primary SRP HD keyring accounts
  • This doesn't change the current implementation of account syncing, it will only ensure that if multi-SRP releases before account syncing fully supports it, nothing will break and account sync will still work at least the same as of right now
• During account syncing, new accounts will be added in bulk
  • This will vastly improve client performance by being able to batch RPC calls that previously happened sequentially when we added accounts one by one
  • We are then removing the maximum accounts to sync limit

Related issues

Related to:

• https://consensyssoftware.atlassian.net/browse/IDENTITY-28
• https://consensyssoftware.atlassian.net/browse/IDENTITY-6

Manual testing steps

1. Import an SRP with a lot of accounts synced
2. Verify that every account is added
3. Verify that you can sync more than 100 accounts

Screenshots/Recordings

Before

After

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]

Updated dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/@metamask/[email protected] 🔁 npm/@metamask/[email protected]	None	0	0 B
npm/@metamask/[email protected] 🔁 npm/@metamask/[email protected]	None	0	1.49 MB	metamaskbot

View full report↗︎

[metamaskbot]

Builds ready [015c562]

• builds: chrome, firefox
• builds (flask): chrome, firefox
• builds (MMI): chrome
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

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

Page Load Metrics (1979 ± 134 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	395	2749	1905	445	214
		domContentLoaded	1588	2720	1937	282	135
		load	1649	2741	1979	280	134
		domInteractive	27	206	72	52	25
		backgroundConnect	12	83	39	23	11
		firstReactRender	15	90	33	24	11
		getState	7	64	25	21	10
		initialActions	0	0	0	0	0
		loadScripts	1148	2190	1450	260	125
		setupStore	7	64	21	20	9
		uiStartup	1879	3099	2248	299	144

Bundle size diffs [🚨 Warning! Bundle size has increased!]

• background: 190 Bytes (0.00%)
• ui: 0 Bytes (0.00%)
• common: 1.6 KiB (0.02%)

[mirceanis]

This jumps out at me as something that we won't detect as a problem some months down the line because in tests it doesn't show up.
I suspect I half know the reason for this but I wonder if we are still bound by the same constraints here

[mathieuartu]

@mirceanis The QA team would know, believe me 😂 When we didn't have a limit, we (righfully) received a lot of complaints.
But yeah, jokes aside, there's no clear way of testing this because we don't expose the result of this config publicly from the controller.

But all in all, I'd say last week incident was in fact caught by @cmd-ob so I'm confident to include this line as well

[mirceanis]

got it, but can we make it a bigger number, and something unique that would raise eyebrows, like 420 or 1337?