feat: shield-controller: check signature coverage

[matthiasgeihs]

Explanation

This PR adds support for validating signature coverage to the ShieldController.

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​metamask/​signature-controller@​33.0.0

View full report

[socket-security]

All alerts resolved. Learn more about Socket for GitHub.

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

Ignoring alerts on:

• @metamask/signature-controller@33.0.0

View full report

[matthiasgeihs]

@SocketSecurity ignore npm/@metamask/signature-controller@33.0.0

[lwin-kyaw]

Please note that we can't always except coverageId to be in the response, with the 200 status.

Please check the swagger, as it has updated recently. (please select schema tab under the 200 response, not the example value)

[lwin-kyaw]

The sample cases of 200 responses without coverageId ~

• where origin is localhost or empty string (requests directly from metamask wallet)
• when providing invalid chain id values

In such cases, we don't proceed to process the rulesets, we straight away return the Unknown result from the server.

[lwin-kyaw]

This case also applies to transaction-coverage

[matthiasgeihs]

Why don't we throw an error in that case?
So basically now the init endpoint can also return a result? Kind of confusing. This creates unnecessary edge cases I believe.

[matthiasgeihs]

Can we please change the API backend. I do see several issues with this change. The expectation so far is that if we have a coverage result, either for signatures, or for transactions, it always has the same format. If we don't have that, a lot of complexity is added to the whole system. (Currently we can just treat the results within the same data structure. Then we might need separate data structure. Also, missing the coverageId might be problematic because it means we can't look up the corresponding backend calls.)