feat: always use snaps to resolve domains; include preinstalled ENS r…

…esolver snap (#26242)

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

The embedded ENS resolution logic is being replaced by snaps that use
`endowment:name-lookup`.
This change-set also includes a preinstalled snap that does ENS
resolution including ENS multi-coin functionality.

The ENS resolver snap will use the Ethereum provider from the extension
on Ethereum mainnet and ENS supported testnets and will revert to an
Infura JSON-RPC when the extension is connected to other networks. On
other networks it tries to resolve the [network-specific ENS
address](https://eips.ethereum.org/EIPS/eip-2304) and if none exists
will try to resolve the mainnet address (with a ⚠️ warning) as long as
that address appears to be an externally owned account.

Most of the relevant changes are in `domains.js`.
Since the preinstalled snap uses ethers v6 while the extension depends
on ethers v5.7 there are some changes in the lavamoat policies. Also,
the more recent ethers version requires a different set of mocks,
requiring a small change in the e2e test.

[![Open in GitHub
Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/MetaMask/metamask-extension/pull/26242?quickstart=1)

## **Related issues**

fixes MetaMask/MetaMask-planning#2403
closes #18035
fixes #18648
fixes #22797
fixes #8556
fixes MetaMask/specifications#11

## **Manual testing steps**

1. While on Ethereum mainnet, start a send flow
2. Type an ENS name in the recipient field(example _vitalik.eth_), pick
the resulting address. (this should be identical to previous behavior)
3. Switch to a L2
4. Type an EOA ENS name in the recipient field (example _vitalik.eth_),
observe an address being resolved with a ⚠️warning.
5. Type an ENS name that would resolve to a contract on mainnet (example
_uniswap.eth_). Observe `No resolution for domain provided.` error.

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->



https://github.com/user-attachments/assets/6e8866ef-f478-4647-a0f0-f1c13342edd1



## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask
Extension Coding
Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I’ve included tests if applicable
- [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)).
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.

---------

Signed-off-by: Mircea Nistor <[email protected]>

.depcheckrc.yml

@@ -28,6 +28,7 @@ ignores:
   - '@sentry/cli' # invoked as `sentry-cli`
   - 'chromedriver'
   - 'depcheck' # ooo meta
+  - 'ethers' # ethers @5.7.0 expected by @account-abstraction/contracts, but conflicts with transitive [email protected]
   - 'ganache-cli'
   - 'geckodriver'
   - 'jest'