Improved lockfile support to prevent concurrent modification of state
We should do smarter about multiple processes using the same state files at the same time.
Right now we use advisory locking via the [This issue was fixed.]fslock
crate, which does not yet always behave right with a single process opening the same file more than once. But see this PR.
After that is fixed, we should make the state code smarter about lock collisions. I'd prefer to be in a situation where failing to get the lock just puts us into a "read-only" state, where we just take the other process's word about the current guards and circuit timeouts.
Edited by Nick Mathewson