[SRU] Backport wsl-pro-service to Jammy

[Carlos Nihelton]

As part of our offerings to bring Ubuntu Pro to wider audiences we need to backport this service to Ubuntu 22.04 LTS, so users can benefit of the upcoming GA of Ubuntu Pro for WSL, as Windows system that allows more easily secure and manage WSL instances, by automatically pro-attaching Ubuntu on WSL instances and even register with and manage them via Lansdcape.

wsl-pro-service is our bridge to the Windows application that performs key post-provisioning actions on an instance, such as updating a Pro token and Landscape configuration data if that changes on the Windows side.

As this service is only applicable for Ubuntu on WSL, its systemd unit is contained to not even start
if the condition `ConditionVirtualization=wsl` is unmet. systemd confinement options were validated to work on Jammy as of wsl-pro-service version 0.1.18 (the one being proposed via this SRU).

[Impact]

* wsl-pro-service is a new package for Jammy
* It depends on golang-1.23-go at build time, which is available on jammy-updates.
* Ubuntu Pro for WSL relies on this service being seeded on the Ubuntu instances.
* That system is not yet generally available, but planned for later this year.
* At minimum Jammy and Noble must be supported, but Focal is planned (provided the toolchain is also backported, see and LP: #2103997 and LP: #2085834).
* Beta customers were already provided with custom images of 22.04 and 24.04 from the get-go.
* As a new daemon, more often inert if the Windows side is not present, this should not affect users experience on Jammy.
* Boot time measurements reveals negligible impact.
* The systemd unit is carefully and purposefully confined to allow only minimum requirements of our application while remaining compatible with systemd v245 (thus, compatible with Jammy).

[ Test plan ]

== 1. Less loging:

* Make sure the Ubuntu Pro for WSL Windows agent is not running:
  - On Windows run `taskkill /f /im ubuntu-pro-agent.exe`
  - Depending on the OS settings elevated permissions might be required.
* Install wsl-pro-service version 0.1.18 on Ubuntu 22.04 on WSL.
* Follow it's journal with `journalctl -f -u wsl-pro.service`
* Notice that it starts logging connection attempts too often, backing off exponentially up to 1min interval.
  Approximately 10 minutes after attempting to connect without success, it silents.
* systemd should take approximately 20 min to attempt to restart the unit.

== 2. Pro attachment works under systemd restrictions and without livepatch being installed.

(Most of this test case would be testing ubuntu-pro-client v35 indeed, but we must verify that our integration
is not harmed with the changes in wsl-pro-service systemd confinement)

* Create a fresh instance of Ubuntu on WSL:
  - On Windows run `wsl.exe --install -d Ubuntu-22.04`
* Install ubuntu-pro-agent v35 (currently available via the `-proposed` repository)
* Make sure livepatch is not installed: `sudo snap remove canonical-livepatch`
* Make sure the Ubuntu on WSL instance is not pro attached: `pro status` (`pro detach` if needed).
* Install wsl-pro-service version 0.1.18 on Ubuntu on WSL (Noble, Oracular and Plucky should behave exactly
the same)
* Install Ubuntu Pro for WSL (download the latest production build from https://github.com/canonical/ubuntu-pro-for-wsl/actions/runs/14386282882/artifacts/2921576467)
* Follow this guide to attach your Pro token: https://documentation.ubuntu.com/wsl/en/stable/tutorials/getting-started-with-up4w/#set-up-ubuntu-pro-for-wsl
* Follow it's journal with `journalctl -f -u wsl-pro.service`:
  - If pro-attaching fails because of systemd restrictions we should see some "permission denied" or "bad system
  call" errors in the journal.
  - If the livepatch fix was not correct, we should see mentions to `canonical-livepatch` in the journal.
  - Both conditions should be considered a failure. Otherwise, proceed.
* Confirm pro attachment `pro status` inside the Ubuntu instance.
* Finally assert that canonical-livepatch remains not installed on this machine.

== 3. (Optional) wsl-pro-service outside of WSL

(Ensures the unit does nothing outside of WSL)

* Install wsl-pro-service on an instance of Ubuntu 22.04 on any platform other than WSL (Desktop,
Server bare-metal or VM, OCI containers).
* Verify that the unit is disabled due unmet condition: `systemctl status wsl-pro.service`

== 4. (Optional) Boot time

(Ensures the unit does not significantly impact the boot time duration)
* Install wsl-pro-service on an Ubuntu 22.04 instance on WSL.
* Modify the default user's .bashrc to just exit (by appending `exit` as the last line of that script)
* On Windows PowerShell run `wsl --terminate Ubuntu-22.04; Measure-Command {wsl -d Ubuntu-22.04}` a few times and take notes of the duration that command takes to finish
* Start the WSL instance as root `wsl -d Ubuntu-22.04 -u root`
* Remove wsl-pro-service
* Repeat the measurement step
* Compare the results.

Spot differences are expected, because of the many layers involved, but there should not be more than 2% difference in **median** between boot times with and without that service enabled, per recent measurements taken by our team.

[ Where problems could occur ]

The few beta customers we have might have noticed that up until now, wsl-pro-service remains running all the time the unit is alive, thus anytime a user installs the
Ubuntu Pro for WSL application on Windows they could expect the communication with the Windows agents to start
briefly. That's also the case for the custom 22.04 images they've been playing with, which come with wsl-pro-service 0.1.5.

With the behaviour changes in v0.1.18, that won't be the case always, as the service could just had quit seconds before
and systemd will take about 20min to restart it. Users can always `sudo systemctl restart wsl-pro.service`.

Since the entire system is not yet generally available the number of users affected by this behaviour change
is very minimal, comprising of a handful of beta testers and internal collaborators (such as the
Landscape team).

If the changes in wsl-pro-service landed before ubuntu-pro-client v35, we'd have issues with livepatch already
described. I judge that as almost impossible since the SRU bug LP: #2083973 is older and is very likely to
handle any regressions in time.

[ Other Info ]

I intentionally skipped testing the changes related to Landscape because it's too complex to set up a server
just for this purpose.

[Carlos Nihelton (cnihelton)]

Proof of build can be seen in this PPA: https://launchpad.net/~cnihelton/+archive/ubuntu/pplayground/+packages?field.name_filter=&field.status_filter=published&field.series_filter=jammy

The version numbers are slightly changed because I wanted to make sure the archive will contain a higher version number in the end. Contents are essentially the same.