Description

In the quest to improve all of our I/O and make it race-free, one thing remaining is exclusive locking of the validator_definitions.yml.

The problem is that account manager commands currently cannot tell if the validator_definitions.yml is in use by a validator client, which introduces the possibility for data races. As an example:

1. VC starts, it loads the file and keeps a copy in memory
2. (concurrent with 3) The user creates a new validator via the API. This mutates the in-memory definitions and queues a disk write via ValidatorDefinitions::save.
3. (concurrent with 2) The user disables an existing validator using the account manager (per [Merged by Bors] - Add an account command to enable/disable validators #2386). This has the same effect of mutating the structure in memory and queuing a disk write.
4. One of the writes clobbers the other, because there was no locking and the reads are now stale. It's as if one of (2) or (3) never happened.

In practice this is hopefully unlikely to occur very often, as usually human users will not be making concurrent changes using these two mechanisms so close together. Hopefully automated systems will use the API entirely rather than a mixture of API + account manager, although this is definitely a gotcha to watch out for.

Solution

Using the common/lockfile crate from #1958, add a lockfile called validator_definitions.yml.lock which must be locked by the VC & account manager in order to open the validator definitions.