Support multiple api keys

[kanej]

Etherscan has expanded to provided block explorers and verifiers for popular sidechains. The config in the hardhat-etherscan plugin assumes there is only one apiKey for use in verification, even though the project may be targeting multiple network/sidechains.

This PR adds support in the hardhat-etherscan configuration for setting an api key for etherscan per network (i.e. a project could support project verification on both mainnet and polygon at once without hacks).

Approach

Extend the current allowed structure of the hardhat-etherscan from:

{
   etherscan: {
      apiKey: string, 
   }
}

to:

{
   etherscan: {
      apiKey: string | EtherscanApiKeys, 
   }
}

Where EtherscanApiKeys is an object with one property for each supported network mapping to the apiKey to used when verifying on that network.

The supported networks are derived from the networkConfig object that combines the chainId and etherscan urls, and is used to define the typesafety of the etherscan config object (only networks present on the config object are allowed in a valid etherscan config).

Relates to #1448

TODO

We'll release a new major version.

• Add support for EtherscanApiKeys under etherscan config
• Refactor supported networks so that each one has a name (used in the EtherscanApiKeys type)
• The relationship between supported networks and EtherscanApiKeys should be typesafe
• The key to be used when verifying a contract should be the one that maps to the currently selected network if the using EtherscanApiKeys, or the apiKey string otherwise
• Update the README
• Update the contribution guide
• Manual testing against a sample of alternate networks

[changeset-bot]

🦋 Changeset detected

Latest commit: 6dcf619

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@nomiclabs/hardhat-etherscan	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[fvictorio]

I modified some error messages. I think they look a bit better now:

There is only one extra thing I'd like to have here related to error handling: to show a proper error when the user configures an API key under an invalid network name. This is only relevant for javascript projects, since in typescript that will simply not compile.

I think this is important because it's likely that users won't read the docs, and they'll try to use the network name as the key.

[kanej]

I have added a check on the etherscan api keys during extendConfig, so it throws if a js project has included an unsupported network as a key:

I have repeated the manual test of a verify against ropsten, but that was using the same linking approach as before @fvictorio.

[fvictorio]

Small comments, pre-approving

[Shelvak]

I pulled master and just use the multi-api-key, amazing feature 👍 Thank you so much 🚀 🚀

[fvictorio]

@Shelvak oh, thank you for testing it! We'll probably release this feature this week.