Migrate deployment to use cannon

[kaze-cow]

Description

In order to improve multi-network multi-repository deployments of CoW protocol, we are switching to using Cannon. This retains the existing deployment system. Unfortunately, many of the smart contracts have been updated (causing changes in the deployed contract address of the settlement contract), so techincally these also have to be referted in order for the correct package version to be generated.

Considering the smart contract changes we ultimately want to have in the next settlement contract, it seems smart to move them into a new dev branch which we use as the branch where PRs get merged until we are ready to deploy settlement v1.5

It also includes all the appropriate documentation for continued maintenance and usage of cannon.

Test Plan

Similar to other cannon releases:

• Install dependencies (yarn install)
• Run cannon package build (yarn hardhat cannon:build --network cannon --wipe)
• Verify running yarn record-cannon results in no substantial changes to the recorded package manifest (some changes are to be expected, such as timestamp and chainDumps will change due to the time changing)
• verify tests and etc. in the repo are still working as before

Related PRs

This PR is the product of two previous PRs as I experimented with getting a good implementation of Cannon in this repo.

#255 -- previous PR which also removes hardhat-deploy and has much, much more changes. This PR is much more minimal.
#256 -- this one was supposed to be the "minimized" version, but its based off the main branch which doesn't produce the proper artifacts. This PR is based on new-chain-deployments

[socket-security]

All alerts resolved. Learn more about Socket for GitHub.

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

View full report

[anxolin]

Test plan was great, and worked. Only thing, I saw a incoherence with the generated artifact path in the README.

I checked the contract matches, the tests pass, and the main configs. Looks pretty good.

Description of PR was good, but some things that could be better are

• Title is strange. Should be written like a command you give to the code to change. For example in this case "Migrate deployment to use cannon" or sometihng similar
• The 2 notes are a bit strange, if CI fails, maybe is good we set it up later so we have an independent PR just for that that is more soped and easier to review and test. This PR doess a lot of things at once. Anyways, im not concerns, so don't split it.
• The description feels more like "a context" you are giving, which is nice, but I would love to read as the first part of a description a highlight of what I expect to see later in the code (so I understand the scope). Something like, "This PR includes the migration to cannon, and the following are the main changes:" or sth similar

[anxolin]

@kaze-cow would it make sense to always create the same NPM scripts (same name) in all projects?

For example, this project usesyarn build to build the contracts.

Given this command to build cannon packages don't change (they have the same netork and params).

What do you think we add some convenient scripts:

• yarn build:cannon: would run the 2 commands bellow
• yarn cannon:package: would run yarn hardhat cannon:build --network cannon --wipe
• yarn cannon:registry: Rename for your record-cannon script

Just a suggestion, maybe there's better naming conventions. The point is to have a simple command that is familiar across projects (always the same)

[kaze-cow]

What do you think we add some convenient scripts:

yarn build:cannon: would run the 2 commands bellow
yarn cannon:package: would run yarn hardhat cannon:build --network cannon --wipe
yarn cannon:registry: Rename for your record-cannon script

Just a suggestion, maybe there's better naming conventions. The point is to have a simple command that is familiar > across projects (always the same)

I like the naming approach you suggested. currently we have one script record-cannon shared between projects, but this pattern is intuitive, and unifies the build commands between different repositories. Let me go ahead and set that up in this and the other PRs!

[anxolin]

I see the comments were addressed, and this had an approval already. I assume nothing is blocking this PR