patch breaking change in signTypeData param validation

[adonesky1]

(Hot) Fixes: #11308 & #11296

Explanation: In 9.6 we added a strictEqual check when validating the specified chainId against the current chainId for signTypedData calls, this runs afoul of how the domain data is often formatted (as a string or hex string), causing issues for some developers.

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

[adonesky1]

preserving strict equality check where there is no reported issue.

[metamaskbot]

Builds ready [9627cf9]

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

Page Load Metrics (517 ± 56 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	44	73	60	10	5
		domContentLoaded	350	667	516	117	56
		load	351	669	517	117	56
		domInteractive	349	667	516	117	56

[brad-decker]

LGTM, but I do think going back to legacy assertion is a regression in itself ... We will need to return to this after the patch to figure out how to handle this long term. This is already discussed in internal (slack) communication but wanted to raise it here as well.

[adonesky1]

LGTM, but I do think going back to legacy assertion is a regression in itself ... We will need to return to this after the patch to figure out how to handle this long term. This is already discussed in internal (slack) communication but wanted to raise it here as well.

agreed. In this particular instance could just involve parsing all possible matching chainIds (string, hex, bigNumber) and making sure that the active is in that set?

otherwise @ryanml do we feel good about merging and cutting a patch?

[ryanml]

@adonesky1 - no objections from me, but we should file an issue for followup reasonably soon per @brad-decker

[adonesky1]

@adonesky1 - no objections from me, but we should file an issue for followup reasonably soon per @brad-decker

Just wrote one up: #11310