Verify proxy/implementation on etherscan

[jordaniza]

Description

Adds a call to the etherscan API at the end of the deploy script. This call passes the address of proxy contracts, along with their implementation, to etherscan.

In theory, this should work. In practice the etherscan API on testnets have been extremely unreliable, sometimes verifying, sometimes returning verification errors.

It is possible to re-run the stage with yarn deploy --network XXX --tags VerifyProxies, which will fetch the list of deployment addresses from the build cache. I've had some success waiting for a bit then re-running the step. We may prefer to add some deployment instructions to advise users with errors to wait a while for the block explorer to properly index the contract verification.

Task ID: OS-1062

Type of change

• [x] New feature (non-breaking change which adds functionality)

Checklist:

• [x] I have selected the correct base branch.
• [x] I have performed a self-review of my own code.
• [x] I have commented my code, particularly in hard-to-understand areas.
• [x] My changes generate no new warnings.
• [x] Any dependent changes have been merged and published in downstream modules.
• [x] I ran all tests with success and extended them if necessary.
• [ ] I have updated the CHANGELOG.md file in the root folder.
• [x] I have updated the DEPLOYMENT_CHECKLIST file in the root folder.
• [x] I have updated the UPDATE_CHECKLIST file in the root folder.

[jordaniza]

I left a few comments.

One more thing: Do we need mock-deployments.json to be tracked with git or should we .gitignore it?

I think we should commit this file, it is a hardcoded snapshot of a point in time deployment and so is not autogenerated. We could strip much of the data out and keep the mock minimal if you would prefer.

[heueristik]

I left a few comments. One more thing: Do we need mock-deployments.json to be tracked with git or should we .gitignore it?

I think we should commit this file, it is a hardcoded snapshot of a point in time deployment and so is not autogenerated. We could strip much of the data out and keep the mock minimal if you would prefer.

The file is 1.35 MB large, so yes - let's try to reduce file size.

[jordaniza]

I left a few comments. One more thing: Do we need mock-deployments.json to be tracked with git or should we .gitignore it?

I think we should commit this file, it is a hardcoded snapshot of a point in time deployment and so is not autogenerated. We could strip much of the data out and keep the mock minimal if you would prefer.

The file is 1.35 MB large, so yes - let's try to reduce file size.

Trimmed to just the addresses and added a comment to explain it

[jordaniza]

Adding the delay didn't resolve the issue on Optimism Sepolia. Need to understand why but will require further investigation. Moving the PR to draft for now and will revisit once I have time.