A follow up to 0faacaa7c8 to cover the stop button within the launcher
and terminating Syncthing on shutdown/exit. To find the relevant connection
the connection settings are searched for a local URL where the port matches
the port from the Syncthing process log.
Loading the icon for the button from resources ceased to work (maybe when
switching to `PlasmaComponents3.ToolButton`). This change works around the
problem and the old icon no longer needs to be bundled.
Syncthing can report an "idle" status despite pull errors. This still means
the directory is out-of-sync. With this change the out-of-sync status is
only cleared when reading a "FolderSummary" event without pull errors (or
temporarily if the directory is e.g. scanning).
Syncthing's official web UI also does the first query for events like this.
This should make loading times a bit faster and removes the possibility of
picking-up obsolete events (which was always problematic).
See comment; otherwise calls to `readAll()` with no `bytesAvailable()`
like done in the `syncthingctl` tests fail sporadically as async read
operations are started concurrently.
If there's a configured and local Syncthing connection and we're on a
non-UNIX platform which doesn't support SIGTERM (basically Windows) it
makes sense to use the REST-API instead. That's likely better than just
terminating the process forcefully.
This doesn't cover the stop button within the launcher settings yet because
from this context is isn't clear which connection is relevant as there can
be multiple tray icons/widgets but only one settings page.
Otherwise `QMetaMethod::invoke` wouldn't be able to handle it:
```
QMetaMethod::invoke: Unable to handle unregistered datatype 'QProcess::ProcessError'
```
* Use a process group / job object via Boost.Process to be able to
terminate sub processes as well
* Do not try to stop the process gracefully under Windows by posting
WM_CLOSE because this has no effect on Syncthing anyways
* See https://github.com/Martchus/syncthingtray/issues/94