[WORKING DRAFT] User services on SailfishOS

Certain use-cases of some applications require work to be done in the background.
Apps like clients to certain cloud storage solutions (like ownCloud) would like
to provide automatic backups of photos taken with the camera.
UX-wise it is bad to have the user remember to start certain applications after the device has booted.
Application developers could decide to split apps into two separate programs, a GUI and a daemon.
As SailfishOS already makes use of systemd user sessions this could be used to handle
service management of user-installed applications inside ~/.config/systemd/user/.

What we don't want:
* Allow arbitrary applications to write to ~/.config/systemd/user/
* Allow arbitrary applications to enable/disable services of other applications
* Get in the way of possible sandboxing methods
* Start services at boot without the user having explicitly enabled them

What we want:
* Use systemd user session to keep track of service process
* A trusted userspace daemon dealing with enabling/disabling services

Other possible ideas:
* Multiple services per app?
* Guidelines on what the background daemon should be allowed to do?
* Keep services running for a certain amount of time?
* Dependencies? (example: automatic camera photo upload requiring tracker to be running)
* Let services create wayland surfaces for direct interaction?
* Limiting resources (CPU, memory)?

Proposal:
A trusted userspace daemon (either a new one or the compositor) could provide
dbus interfaces to allow applications to enable/disable their respective background services.
This daemon would be the only process allowed to write to ~/.config/systemd/user/.
When the user starts an app and explicitly enables the autostart of the apps service
the trusted daemon could show a dialog to allow the user to cancel or proceed enabling the service.
The trusted daemon would then check for the calling process of the dbus method and create
a minmal service file like:

[Unit]
Description=harbour-<APPNAME>

[Service]
Type=simple
ExecStart=/usr/share/harbour-<APPNAME>/daemon


...where /usr/share/harbour-<APPNAME>/daemon is the binary which implements the
applications background functionality. This service file would be written to ~/.config/systemd/user/.
The trusted daemon would know which service to activate since only the application itself is
allowed to enable/disable it's respective service.
Also, since only the trusted daemon is allowed to write to ~/.config/systemd/user/ it can decide on
resource limitation and guarantee a working start of lipstick (by not allowing a reverse-dependency).
TODO: should the service file contain [Install] information?
If yes: should the [Install] contain configurable dependency or be soley dependent on lipstick?
If no: probably needs a separate file to keep track of enabled services and let the trusted daemon
start them when UI is up.