code duplication between FsStateMgr and state_dir (!1853)

Hi, @nickm, you asked me to write a ticket about state_dir vs tor_persist::FsStageMgr.

I think the situation is like this:

Background, contents of the state_dir structs: state_dir::InstanceStateHandle will have a CheckedDir for the instance-specific state directory, and a lock guard (the lock guard is in the sketch state_dir.rs; the CheckedDir isn't but one couldn't implement it wihtout). state_dir::StorageHandle needs to contain a representation of the path, maybe a mistrust, and another clone of the lock guard, in order to implement the store/load/delete methods.

The actual implementation of the store/load/delete methods needs to be quite similar to those in tor_persist/src/fs.rs. (FsStateMgr::load and store)

But state_dir can't call that code because it's entangled with FsStateMgr which has its own locking arrangements. (I'm pretty sure state_dir doesn't want to try to reuse FsStateMgrs locking arrangements, since state_dir has different semantics.)

Looking at the amount of code invovled, it's 40loc including all the generics etc., so maybe just c&p it is OK. It doesn't fill me with happiness.

The obvious answer is to move the implementation of FsStageMgr::load and store into free functions that take an &CheckedDir or a &Path, and rely on the caller to do any locking. Then state_dir could just call those.

I'm not sure we want to expose those as a public API of tor-persist though. Maybe instead, we should move state_dir to tor-persist before we implement it, rather than trying to keep it in tor-hsservice. That would make this trivial.

In terms of what I'd like from you: I think the actual code movement or whatever here is straightforward. What I think is needed is a decision about what approach to take.