Support for snapshot sync at mount

[Musholic]

I've implemented the proposal in #68 with a few tests (base mount/umount logics + different usual scenarios). I'm keeping the changes as simple as possible, let me know what you think

The implementation follows this logic:

• Add a new schedule named "snapshot_sync", which will be used to know if we want to automatically restore newer snapshots at mount. And at unmount, it will automatically snapshot and send it
• This new schedule will work the same way as replicate, in addition to the mount/unmount logic
• Support for adding schedules automatically at volume creation: may not be necessary, but it felt really better with it (and this was simple enough to implement). The only downside is that we have to delete the schedules manually if we don't want them anymore, but it should be ok for now
• Refactor of several functions, especially since I apparently could not reuse directly the route method, which I suffixed with _req
• Prevent the creation of empty snapshots, as it may conflict if the service is moved to another host, but we kept creating snapshots on other hosts. It's using a quick and efficient check based on btrfs send/receive
• Prevent sending the same snapshot to the same remote (since we don't necessarily create new snapshots every time we replicate)

I plan to implement the support for multiple hosts in another PR, as I may have to deal with timeouts and connection errors to handle the case where one of the hosts is unresponsive.

I've tested the PR on my own setup, and I think it's ready to be merged. Let me know if you are willing to merge it, and then I can also update the documentation to finish the PR (or in a second PR).

TODO:

• Document the new "snapshot_sync" schedule and the new "schedules" option
• Fix snapshot still created on "inactive" hosts

[Musholic]

Note that I added several fixes that I felt were necessary. I started using it on several docker swarm services this week, and it's working really great (with the fixes). I'll keep monitoring and testing other common scenarios next week