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.
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
* Use local time consistently for timestamps which might get displayed
within the UI, e.g. the dir status was in one case set to the local time
and in other cases GMT was used which could lead to discarding status
updates
* Print warning when timestamp parsing fails (instead of ignoring it
silently)
* Set directory status from folder status response even when parsing the
timestamp fails
* Catch possible exception when printing log timestamps in syncthingctl
See the commit message of the corresponding commit in c++utilities
(9fb3bbe179698fb10339d4911b98531b0847cfa1) and also the related commit in
reflective-rapidjson (5c49a438ade5ae4253ae978e3a22cf88bd7cb2e2).
because notifications have nothing to do with the status and it should not
make a difference since the status would not change. The UI is supposed to
rely only on newNotification().
Martchus