Adds ViemSigner compatibility layer

[douglance]

• AssetBridgers can be instantiated with a provider from ethers v5, v6, web3, or viem.
  • Question: Do we want to remove the support for ethers v6 and web3?
• Signing can be done with ethers v5 or viem signers.
  • consuming packages must instantiate a ViemSigner using createViemSigner before passing in the signer to the sdk.

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Default Name.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email [email protected]
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[fionnachan]

what's happening here with the @ts-expect-error?

[douglance]

We access private fields, but they're not true private fields. We can still access them, but TS doesn't like us accessing them.

[fionnachan]

i think we should also have unit tests for this one

[douglance]

added unit tests 77290dd

[fionnachan]

why wouldn't you use ethLocal here?

[fionnachan]

Is this to create a copy and make sure request is not changed?
It is viem's responsibility to ensure the function doesn't create side effects to request, and by the look of its code we should pass request directly
https://github.com/wevm/viem/blob/main/src/actions/wallet/sendTransaction.ts#L121

unless we are passing additional params than request, I don't see why we should spread it

[fionnachan]

this set of description doesn't match with what's in the tests

the tests are creating different providers and testing each of them against whether they are ethers v5 provider

whereas the description says
here's an ethers v5 provider, it should return an ethers v5 provider,
here's an ethers v5 provider, (?) should correctly identify it's a v5 provider,
here's an ethers v5 provider, (?) should correctly identify it's not a v6 provider,
here's an ethers v5 provider, (?) should correctly identify it's not a web3 provider

so i'd either change the tests to:

describe('Provider Utilities', () => {
  describe('ethers v5', () => {
    it('should return the URL for an actual EthersV5 provider', () => {
      const provider = new JsonRpcProvider('http://localhost:8545')
      const url = getEthersV5Url(provider)
      expect(url).to.be.equal('http://localhost:8545')
    })

    it('should be correctly identified as an EthersV5 JsonRpcProvider', () => {
      const provider = new JsonRpcProvider('http://localhost:8545')
      expect(isEthersV5JsonRpcProvider(provider)).to.be.true
    })

    it('should not be identified as an EthersV6 provider', () => {
      const provider = new JsonRpcProvider('http://localhost:8545')
      expect(isEthersV6JsonRpcProvider(provider)).to.be.false
    })
   ...
  })

or

describe('Provider Utilities', () => {
  describe('isEthersV5JsonRpcProvider', () => {
    it('should correctly identify an EthersV5 JsonRpcProvider', () => {
      const provider = new JsonRpcProvider('http://localhost:8545')
      const url = getEthersV5Url(provider)
      expect(url).to.be.equal('http://localhost:8545')
      expect(isEthersV5JsonRpcProvider(provider)).to.be.true
    })

    it('should correctly identify an EthersV6 provider is not an EthersV5 provider', () => {
      const provider = new JsonRpcProviderv6('http://localhost:8546')
      expect(isEthersV5JsonRpcProvider(provider)).to.be.false
    })
   ...
  })

something along those lines ^
feel free to figure out what's best