Decide how to proceed with Etherscan API key parameter

[manuelwedler]

Currently, the API key parameter of the Etherscan import is optional (API v1 + v2). We are running into being frequently rate limited by Etherscan with our own API key due to that. We should make a decision for how we will handle this in the future.

Options:

• Make the API key required
  Pros: We don't get rate limited with our own API key.
  Cons: Worse UX
• Keep the API key optional
  Pros: Easier to use the API and people might not be willing to send their API key to the Sourcify server.
  Cons: We still run into being rate limited with our own API key.
• Introduce rate limiting into the API if the key is not provided
  I think this is actually a good middle way between the options above. People who heavily use the API will be forced to provide an API key. Users that just want to import a single contract through the UI will not be affected by Etherscan's rate limiting on our API key.

Whatever we do should be consistent across API v1 + v2.

[marcocastignoli]

Introduce rate limiting into the API if the key is not provided

I'm for this 👍 Only downside is that we would have to re-implement a rate limiter in sourcify just for that. I don't think we can specify a rule on GCP