Run uStreamer via a launcher

[mtlynch]

This changes the uStreamer installation so that the uStreamer systemd service runs a uStreamer launcher script rather than running uStreamer directly.

The launcher script, at runtime, reads a set of configuration files, translates those configuration files to uStreamer's command-line flags, and launches uStreamer with those flags.

In the previous implementation of this role, clients needed to re-run Ansible in order to change any of uStreamer's settings (e.g., frame rate, quality) because Ansible was responsible for generating the command-line string to launch uStreamer.

In this implementation, clients can change uStreamer's settings without using Ansible. Clients can simply change settings in the uStreamer launcher's config files and restart the uStreamer service. When the service restarts, the uStreamer launcher will pick up the new configuration.

This reduces the time to change video settings by 91%.

See a rough proof of concept in TinyPilot Pro: https://github.com/tiny-pilot/tinypilot-pro/pull/701

Implementation notes

• files/launch deliberately doesn't use Ansible role variables because I want to make it easy to move this script to Debian packages in the future.
• The design of having the config files as ordered files in /opt/ustreamer-launcher/configs.d/ is to make it easier to translate the logic to Debian packages in the future.
  • The uStreamer Debian package will be responsible for placing /opt/ustreamer-launcher/configs.d/000-defaults.yml.
  • The TinyPilot Debian package will be responsible for placing /opt/ustreamer-launcher/configs.d/100-tinypilot.yml.
  • This is similar to how nginx works with sites-enabled so that different Debian packages can own files that affect uStreamer's behavior without colliding on trying to own the same files.
• I'm leaving in a debug play, which we normally don't do, but I think we should take advantage of it more.
  • It makes it a lot easier to debug the role, so it's like logging that's just helpful even when we're not actively debugging.
• To avoid complicated coordination of merge order between this PR and the TinyPilot PR, we're leaving in the systemd-config tags and tracking their removal in https://github.com/tiny-pilot/ansible-role-ustreamer/issues/90

Benefits

If we switch TinyPilot over to using this role (which should be pretty straightforward), we get a slew of benefits:

• Increases performance by 91%
  • In my tests, changing uStreamer settings through TinyPilot's video settings dialog went from 17.9s to 1.6s
• Reduces our dependency on Ansible
  • We are adding some more Ansible code here, but I wrote it so that it would be easy to translate to a uStreamer Debian package in the future.
  • We're getting rid of a big dependency in that we no longer need Ansible to change uStreamer settings, which was an annoying obstacle before.
• Decreases fragility
  • It used to be that the /opt/tinypilot-privileged/scripts/update-video-settings script pointed to a file in /opt/tinypilot-updater, which was confusing and brittle.
  • We eventually want to get to a place where the installer files don't need to hang around after installation/update is finished, and this gets us closer to that.
• Backwards-compatible
  • Code written for the previous version of the role should still work on this one, though it's easy for clients to take advantage of the new design.

Drawbacks

• Values from /home/tinypilot/settings.yml will appear in both 000-defaults.yml and 100-tinypilot.yml
  • This isn't a problem with this role but more in how we've implemented the TinyPilot Ansible role on top of it.
  • The TinyPilot role reads from /home/tinypilot/settings.yml and uses those values in the Ansible execution of the TinyPilot and uStreamer role.
  • That means if there are uStreamer variables in /home/tinypilot/settings.yml, they get copied to /opt/ustreamer-launcher/configs.d/000-defaults.yml whenever the uStreamer role runs.
  • The TinyPilot Debian installer also symlinks /opt/ustreamer-launcher/configs.d/100-tinypilot.yml to /home/tinypilot/settings.yml because legacy installations wrote their settings to settings.yml, and it's hard to change at this point.
  • Our design accounts for this, as 100-tinypilot.yml overrides settings in 000-defaults.yml, but it's still a bit untidy.

[mtlynch]

Automated comment from CodeApprove ➜

⏳ @jdeanwallace please review this Pull Request