There is no technical reason for this at the moment, but UEFI is the de
facto firmware for x86-64, so let's be modern.

This should not change anything as the VMs are short-lived (15 minutes
at the most), so it is just added for good measure.

From the kernel patch series[1]:
"This series provides an asynchronous means of reporting free guest
pages to a hypervisor so that the memory associated with those pages can
be dropped and reused by other processes and/or guests on the host.
Using this it is possible to avoid unnecessary I/O to disk and greatly
improve performance in the case of memory overcommit on the host."[1]

The runner hosts may be memory overcommitted if there is too many
running VMs and containers at the same time, which this should help to
avoid.

[1] https://lore.kernel.org/linux-mm/20200211224416.29318.44077.stgit@localhost.localdomain/

This means that there is no need to make runner-specific changes to the
image, so in theory the image could be build centrally (e.g. in the
arch-boxes project[1]) and then distributed to the runner hosts.

This change also make the SSH keys ephemeral.

[1] https://gitlab.archlinux.org/archlinux/arch-boxes

The prepare stage runs "echo "Running on $(hostname)...""[1], resulting
in "bash: line 7: hostname: command not found" and it outputting
"Running on ..." as the hostname command is provided by inetutils, which
is not installed.

Fix it by "monkey patching" it to use "hostnamectl hostname" and inject
the hostname with SMBIOS[2][3]. Injecting creds with SMBIOS may also be
useful in the future, e.g. for injecting an ephemeral SSH public key.

[1] https://gitlab.com/gitlab-org/gitlab-runner/-/blob/v17.5.2/shells/bash.go?ref_type=tags#L452-L456
[2] https://systemd.io/CREDENTIALS/
[3] https://github.com/systemd/systemd/pull/30814

It was forgotten once[1] to update it in both places, so avoid that
issue in the future, by moving it to a variable.

[1] c370c9d0 ("gitlab_runner: Update concurreny math to reflect the new VM size")

This is required f.e. for the dbscripts pipeline where kcov coverage
requires quite a bit more memory and fails to run in parallel with 1GB
limit.

Changes:
- Switch to arch-boxes' base image
- Verify the base image's signature
- Use the new "latest" symlink, instead of parsing the HTML for
  finding the latest arch-boxes image[1]
- Create the base image by using arch-chroot and friends, instead of
  creating a full-blown VM
- Create the VMs from domain XML template instead of virt-clone
- Switch mirror to geo.mirror.pkgbuild.com
- Try to follow "filesystem hierarchy" standards for where to place
  configuration (id_ed25519) and "vendor data" (arch-boxes.asc and
  domain_template.xml)
- Use a ed25519 key instead of RSA key
- Only start the "update base image" server if network and DNS are up
- Misc fixes and cleanups

[1] !552