feat: Auto grant EVM permissions to preinstalled Snaps

[FrederikBolding]

For preinstalled Snaps that use endowment:ethereum-provider, we want to automatically grant permissions to EVM accounts so that the Snap can propose signatures without connecting first. This PR adds a middleware that automatically grants the required permissions when all accounts are not permitted. Otherwise it is a no-op.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.24%. Comparing base (a9f0277) to head (9d50d65).
Report is 7 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3410   +/-   ##
=======================================
  Coverage   98.23%   98.24%           
=======================================
  Files         406      408    +2     
  Lines       11456    11513   +57     
  Branches     1778     1791   +13     
=======================================
+ Hits        11254    11311   +57     
  Misses        202      202           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jiexi]

is this a permanent thing? This may be a bad suggestion, but could we do the following:

1. Add a new permission with origin endowment:ethereum-provider
2. Give this permisssion subject entry all the permissions necessary (and keep it up to date with state change listeners)
3. Rather than granting the permission, rewrite the origin of the request to be endowment:ethereum-provider
4. Allow the request to continue down the pipeline

I imagine there are unwanted side effects of doing the above though

[ffmcgee725]

[nit] we could add @metamask/chain-agnostic-permission package as devDependency and use Caip25CaveatType and Caip25EndowmentPermissionName consts here

[FrederikBolding]

I intentionally skipped out on adding it as a dependency to keep our dependency tree small. Otherwise it often makes releasing painful. I think in this case it doesn't matter too much for just these two strings.

[FrederikBolding]

is this a permanent thing? This may be a bad suggestion, but could we do the following:

1. Add a new permission with origin endowment:ethereum-provider
2. Give this permisssion subject entry all the permissions necessary (and keep it up to date with state change listeners)
3. Rather than granting the permission, rewrite the origin of the request to be endowment:ethereum-provider
4. Allow the request to continue down the pipeline

I imagine there are unwanted side effects of doing the above though

I would strongly prefer not modifying the origin of the requests.

But yeah, I would see this as a permanent thing, we want preinstalled Snaps to be able to use our APIs without having to connect.

[adonesky1]

I would strongly prefer not modifying the origin of the requests.

But yeah, I would see this as a permanent thing, we want preinstalled Snaps to be able to use our APIs without having to connect.

I also prefer what @FrederikBolding has here to your suggestion Jiexi. I think modifying the origin of the request is a very dangerous pattern to introduce at all.

[adonesky1]

LGTM