Timelock authorizer configuration CI

[jubeira]

Description

This PR introduces:

• Automatically generated configuration files for the Timelock Authorizer.
• On-chain enforcement for the suggested configuration (to be executed every day).

If the contract is deployed in a given network, the new task build-timelock-authorizer-config creates a JSON file based on the input configuration for the deployment. The file specifies the delays set for granting / executing action IDs.

Then, the task check-timelock-authorizer-config verifies the integrity of the file (similar to the address lookup system).

Networks that have the Timelock Authorizer should have a non-empty config file, and the file has to match the input specs. This will now be enforced by CI.

The on-chain verification will fail whenever a new rule is added. In particular, it fails right after the deployment because setting the initial delays takes at least 5 days.

I think this is good enough for a first iteration. Eventually the scheduled actions to set the delays shall be executed and the jobs should stop failing.

As a second iteration, we can dig in the scheduled actions, check whether the specified rules are scheduled, and if they are scheduled but still cannot be executed the job should pass.

Type of change

• [ ] Bug fix
• [ ] New feature
• [ ] Breaking change
• [ ] Dependency changes
• [ ] Code refactor / cleanup
• [ ] Documentation or wording changes
• [x] Other

Checklist:

• [ ] The diff is legible and has no extraneous changes
• [ ] Complex code has been commented, including external interfaces
• [ ] Tests are included for all code paths
• [ ] The base branch is either master, or there's a description of how to merge

Issue Resolution

[jubeira]

I've tested the verify task with the first deployment and with the original delays, and it seems to be working properly.

CI task will fail until the delays can actually be applied, and there's always a minimum delay of 5 days for that. That's what is happening with the currently selected deployment (which btw will be overridden once again by #91). I'll think how to improve this a bit.

[jubeira]

The current state should be good to review as a first approach.

Fixing the jobs while the delays are scheduled but not executed would take some more work, and while desirable I think it's not a huge return for the work at this point.

[jubeira]

• Goerli finalize migration tx: https://goerli.etherscan.io/tx/0x2d00c2c9bb10added5824e74565f4a0298c693b2f039ade180d2e972ce67c600
• Sepolia finalize migration tx: https://sepolia.etherscan.io/tx/0x4703149c0f1d308a3c337f518dcb99c853df652993e6ff9f194728299d267035

[jubeira]

Ok, this is pretty cool.

• Sepolia checks right before executing delays.
• executeDelays tx
• Sepolia checks after executing delays

[jubeira]

But I think it needs a bit more documentation (e.g., the name of the onchain verification task in the description), and especially what happens when it's deployed on a new network, and when something is changed on chain, like a delay is added or changed. We have to change the input config to keep up with it?

I've modified the scripts a bit so that it's now mostly automatic. We should document somewhere the need for the settings file though.