Seperate mounting from serving, and add multithreaded serving

[wmanley]

The new mount3 and serve_fs_sync_forever APIs allow for more control over the lifecycle of your filesystem. Mounting the filesystem is now separate from the request handling loop. We also apply the typestate pattern to handle filesystem init, rather than having that as part of the request handling loop.

This provides additional flexibility. We no longer need to implement BackgroundSession, users can just as easily call thread::spawn themselves.

Example equivalent to mount2:

let fs = MyFS {};
let (chan, mount) = mount3("/my/mountpoint", &[])?;
serve_fs_sync_forever(chan.init()?, fs)?;

Example equivalent to Session...::spawn():

let fs = MyFS {};
let (chan, mount) = mount3("/my/mountpoint", &[])?;
thread::spawn(|| serve_fs_sync_forever(chan.init()?, fs)?);

rather than having specific APIs to enable background thread operation.

I've also added serve_fs_mt_forever enabling multi-threaded filesystems using rayon. I'm quite pleased with how its worked out as I've been able to add this without having a separate Filesystem trait taking &self instead of &mut self.

Raising as a PR now for early visibility.

TODO:

• [ ] Document the new APIs
• [ ] Finish making "simple" example multithreaded

[cberner]

Thanks, this looks cool! I've wanted to have multi-threaded support for a while. I haven't read through it all yet, but a couple early bits of feedback: 1) I don't really like the idea of a factory function for Filesystem when using multi-threading. There are a number of cases where you want to have Filesystem be a singleton, such as caching & cache invalidation. The way I'd been thinking of implementing multi-threading was to use async by adding a new Filesystem2 trait that was async 2) what's the use case for splitting serve_fs_sync_forever out of mount3?

[cberner]

Closing due to inactivity, but feel free to re-open, if you work on this more