`camera.pi*` plugins are an exception, as they handle the lifecycle of
the camera streaming process through the `picamera*` libraries.
Otherwise, the streaming thread should explicitly wait on either the
plugin stop or streaming stop events and exit accordingly, or the camera
thread may be streaming indefinitely.
The `_accept_client` logic will be executed anyway at the next
iteration, unless the server socket is closed - in that case, the thread
will fail and exit anyway.
The `wait_for_either` barrier in the streaming thread may instead
prevent other connections from being established after the first one is
closed.
The new authorization flow also requires the user to input a code
returned on the browser's authorization page.
Since the Google authentication libraries seem to use a simple `input()`
to read this code, things are likely to fail quite badly if Platypush is
run in non-interactive mode - e.g. through a systemd service or in a
Docker container.
Thus we need to go with Google's automatic flow only if `DISPLAY` or
`BROWSER` are set (thus the interactive flow can proceed), and throw an
`AssertionError` with the command to execute if no display/browser are
detected.
Expanded explanation of the desktop vs. headless authentication process
and where the credential files are supposed to be copied if the user
opts for a non-automatic authentication flow.
Without this option VLC seems to hang in the background, and it may
cause PulseAudio failures or memory issues after several videos have
been played - each in its own session.
This is useful when users want to use a runnable plugin in a stateless
way. In some cases (for example systems with high latency or limited
quotas for API calls) the user may want to leverage the actions of a
plugin, but without running monitoring/polling logic nor generating
events.