Integrations with OS services

[djdv]

The older prototypes had a service command which exposed subcommands fs service {status|start|stop|restart|install|uninstall}.
The purpose of this was to allow integrations with the host OS, particularly during init. The primary intended benefit here being automatically mounting file systems without requiring user interaction. Typically during boot/init, but also handling whatever particulars exist on other platforms, such as socket activation, automated stop-(re)start under conditions like the host going to sleep, etc.

The older code for these are here (I think this is in the right chronological order):
https://github.com/djdv/go-filesystem-utils/tree/439fcbb37fa7fa546cabf9fc279916e900d672d6/cmd/service
https://github.com/djdv/go-filesystem-utils/tree/144a694322e22d50cc8cbba5f2986f2bbc108b0b/cmd/service
https://github.com/djdv/go-filesystem-utils/tree/e82fdd591887e038cc12bca7bd255da85d6dbe6e/cmd/service

---

From what I remember, the integrations worked fine and even had tests.
But this would still require porting from the old go-ipfs-cmds library to our own command library.
(Should be as simple as ripping out the Run function and putting it into our execute function, and changing how arguments are parsed.)
The library we used was also modified to fix issues across each major platform.
(Some of which were merged back in.)
Fork: https://github.com/djdv/service
Branches of interest: fix/windows, fix/systemd, fix/macos-status, feat/socket-activation

The only remaining thing was rewriting the Linux systemd logic. (This effort was not in-progress.)
Upstream uses handwritten templates, but a Go library for this same purpose exists (https://github.com/coreos/go-systemd) and should be used instead so that everything is (and remains) standard compliant.

There was never anything akin to a persistent fstab in fs mount.
So starting/controlling the fs daemon worked well, but starting it didn't have any useful effect.
The daemon would be running as part of the OS, but the operator would still need to call fs mount as a client to request it to do things on their behalf.

---

To bring this feature back, we need to make sure the daemon logic is behaving properly (we can't afford to make mistakes when running as privileged users / as a system component)
#15

And we'll need to define some format/mechanism for storing the table of file system targets, host mount points, options, etc..
The UNIX analog would be mount -a.
(No tracking issue for this yet)