file_rwlock

file_rwlock

Summary:
The re-architecture puts its state on disk and is concurrently accessed by multiple processes. We need a mechanism to control that concurrent access.

Currently:
* hh uses a load of methods in https://www.internalfb.com/code/fbsource/[f7ecd548b84b]/fbcode/hphp/hack/src/facebook/hh/lib/state_utils.rs
* hh_fanout uses https://www.internalfb.com/code/fbsource/[f7ecd548b84b]/fbcode/hphp/hack/src/facebook/hh_fanout/lib/state/mod.rs
* hh_decl didn't yet implement concurrency control because the available abstractions weren't there and it'd take a lot of work (i.e. this diff) to build them
* closest analogue in hh_server is https://www.internalfb.com/code/fbsource/[f7ecd548b84b]/fbcode/hphp/hack/src/utils/sys/lock.ml, but it really solves a different simpler set of concurrency problems

Writing lockfiles is jolly hard. I think this all merits a single central generic implementation.

This diff adds a new type `FileRwLock<T>`, backed by file and flock(LOCK_EX/LOCK_SH), which is usable as a synchronization primitive by multiple processes. It feels quite similar to `std::sync::RwLock<T>` which is backed by heap memory and is usable as a synchronization primitive by muliple threads. For instance, I used different error types to precisely list the errors relevant to each action, similar to std::sync::{Lock,TryLock}Result. I put in a load of comments, some on the API but most on the implementation, as befits tricky concurrency problems!

Reviewed By: edwinsmith, mjhostet

Differential Revision: D40572127

fbshipit-source-id: 6cf0a82547aeff030765efa6d9ab581ab0952198