BPF CI: Use Debian-based builders

[theihor]

This PR is a part of changes moving BPF CI kernel build jobs environment to a docker image based on debian. Debian is chosen due to it being upstream of Ubuntu, so most scripting is compatible and it is generally lighter and (hopefully) more stable.

Other relevant PRs: libbpf/ci#210, kernel-patches/runner#94

The point of this change is not to switch to Debian specifically, but to battle-test environment customization for BPF CI jobs. If this works well, it's a PoC that BPF CI doesn't actually depend on Ubuntu, or whatever github-hosted runners are using.

Note that this change only affects the build jobs. We are still bound by the requirement to use bare-metal machines to run the selftests without emulation, and so the test jobs will still use ubuntu-based runners for now. However they can already become lighter, because build dependencies won't be necessary anymore.

Background

For mostly historical reasons, BPF CI runners have been tightly coupled to Ubuntu-based environment.

This makes sense, because Ubuntu is the official distro used by GitHub-hosted action runners, and we've been trying to keep BPF CI workflows working on both self-hosted and GitHub-hosted runners.

It comes with drawbacks of course. In particular, because the runners use stable Ubuntu version (24.04 as of today), cutting edge versions of upstream dependencies, sometimes required for BPF testing, may be unavailable out of the box. Because of that, we occasionally have to resort to questionable hackery (example, example).

Another drawback is that BPF CI is down when Canonical is down, because of all the apt install commands across the workflows.

Also we rely on third-party Docker images, which overall have been very helpful, but is another bottleneck. For example, actions runner software can be updated only after upstream image is updated.

AWS CodeBuild

Last year (#346) I set up AWS CodeBuild project in order to be able auto-scale the kernel build jobs on demand. This has been in use without major issues since then.

As it turns out, AWS CodeBuild allows image override directly in the github actions workflow definition (docs). This enables great flexibility in controlling what workflows run in what environment, because we don't have to set up an entire separate runner (from GHA perspective) for every environment. Just specify image uri in the yaml.

This is also better than a vanilla actions container: feature (docs), because the AWS CodeBuild engine has a local docker cache which helps to avoid pulling (or building) the image for every single job. This matters when the image size is 5Gb+.

The cherry on top is that CodeBuild handles part of the self-hosted runner plumbing, such as authentication. The only thing one has to ensure is that the docker image has GitHub Actions runner client runtime dependencies installed. This means that the images running on CodeBuild can be simpler and more lightweight (in terms of stuff installed on the system) compared to what we have now.