ci: containerize ubuntu cli jobs

[tobtoht]

GitHub will begin deprecation of the Ubuntu 20.04 runner in Feb 2025. We support Ubuntu 20.04 until at least Apr 2026.

Proactively containerize both Ubuntu 20.04 and 22.04 to avoid future disruptions.

Edit: drafted because of failing tests:

[  FAILED  ] DNSResolver.IPv4Success (unrelated, see #9709)
[  FAILED  ] DNSResolver.DNSSECSuccess (idem)
[  FAILED  ] is_hdd.linux_os_root

[iamamyth]

Running 20.04 in a container makes sense. Regarding 22.04, how much slower does this make the build? It seems you could just move it when needed, the change would not be terribly complex, and will likely coincide with the promotion of 24 to "popular" and 20 to "no longer supported".

[tobtoht]

Initializing the container and installing packages that would have been installed by default outside of the container takes at most 10 seconds. This is insignificant compared to the usual variance between runs, which is on the order of several minutes.

[tobtoht]

Containerization also has the added benefit of accurately representing the target development environment, so we don't run into a repeat of #9128. Removing the bundled packages can take as much as 10 minutes.

Edit: Using rsync -a --delete /empty/ /usr/local is supposedly faster than rm -rf /usr/local, however still takes several minutes. We can skip this step entirely for containerized builds.

[iamamyth]

You can easily, and quickly, drop the contents of /usr/local with mv (as root):

mv /usr/local /usr/extlocal && mkdir /usr/local && chown --reference=/usr/extlocal /usr/local && chmod --reference=/usr/extlocal /usr/local

[iamamyth]

Why does this action not also run in the container?

[tobtoht]

It is scheduled for removal in #9706, I forgot to mention the soft dependency. Leaving it like this avoids a conflict.

[iamamyth]

Not related to this PR, but it seems this comment very much lost its anchor at some point (I believe it was intended to apply to BUILD_DEFAULT_LINUX; the part about BUILD_SHARED_LIBS no longer appears anywhere in the file). Do you want to open a separate PR at some point to correct the drift?

[tobtoht]

Thanks, I made a note of this.

[iamamyth]

Some clarification of my feedback thusfar may be in order; I meant to signify approval of this line:

Containerization also has the added benefit of accurately representing the target development environment

As far as performance, the relevant measure would be the total addition to build time, not just the setup phase. Because I consider faithful representation of the target environment most important, and "just drop /usr/include" seems a bit finicky, I would favor the container approach even if it adds, say, a minute of overhead; past that, and the tradeoff becomes less clear in my view.

[iamamyth]

The changes here seem reasonable. The test failures owe to a flawed test methodology (fixed in #9709, though I may post additional improvements to that test suite after yours have been merged).