Grace period enforcement for edit commands

[pinebit]

🎯 Problem to be solved

Most of the edit commands replace the existing key shares. The process of cluster editing involves shutting down the VC and Charon instances and then restart with a new set of key shares. The new key shares appear as all new keys to VC and therefore its anti-slashing database will not work as expected (updating this DB is another concern that is to be managed separately from this ticket). To prevent double signing reliably, it is recommended to enforce a pause (grace period of two complete epochs) between shutting down and restarting of those components, and Charon shall enforce this.

🛠️ Proposed solution

• Approved proposal - read below.
• Core team consensus on the proposed solution

A proposal is to extend lease-lock pattern already embedded in the codebase as follow:

• Charon will update the lease lock with the most recent timestamp of the last signing event.
• Every edit command will see this lock file and update it by adding two epochs - that will become the deadline for the enforced grace period; two epoch is the recommended by Ethereum grace period.
• On a new charon run it will verify the current time against the lease lock timestamp and makes Charon waiting for the remaining grace period, after which it simply resumes booting all Charon components.
• If no edit command was executed in between, the lease lock timestamp will always be in past.

The counterpart work that needs to be mentioned here: ObolNetwork/charon-distributed-validator-node#395 - the script that will update anti-slashing DB with the new keys.

Both measures shall reliably mitigate slashing risks.

🧪 Tests

• Tested by new automated unit/integration/smoke tests
• Manually tested on core team/canary/test clusters
• Manually tested on local compose simnet