When there was an error i.e. with the image verification the loopdev
variable was unbound in the cleanup function. We fix this by defining
the variable as empty.

Signed-off-by: Christian Heusel <christian@heusel.eu>

Signed-off-by: Christian Heusel <christian@heusel.eu>

"docker system prune --volumes" does no longer prune named volumes in
Docker 23.0[1][2], so use "docker volume prune --all"[3] for pruning
named volumes.

[1] https://github.com/docker/cli/issues/4028
[2] https://github.com/moby/moby/pull/44259
[3] https://github.com/docker/cli/pull/4229

arch-boxes!182 creates an EFI system partition so rootfs is now in p3.

sq verify --signer-cert now expects a fingerprint/key ID.

The default limits cause issues as reported upstream[1][2], it also
breaks the mkinitcpio CI[3]. So match the limits set in systemd since
v240[4].

[1] https://github.com/moby/moby/issues/38814
[2] https://github.com/containerd/containerd/pull/7566
[3] archlinux/mkinitcpio/mkinitcpio@da223d2f
[4] https://github.com/systemd/systemd/blob/4f44d2c4f76922a4f48dd4473e6abaca40d7e555/NEWS#L6556-L6590

The arch-boxes images now default to Geo mirrors and no longer ship
reflector, so we don't have to disable reflector-init or update the
mirrorlist.

The service was enabled in arch-boxes to account for "hardware clock is
not in UTC, but instead UTC+X"[1], in our case the (VM) hardware clock
is in UTC and we therfor don't need the slow systemd-time-wait-sync
service (+30 seconds).

[1] archlinux/arch-boxes@e23d3c57

Enable kernel lockdown in confidentiality mode to restrict how the root user can interact with the kernel.
See https://wiki.archlinux.org/title/Security#Kernel_lockdown_mode and https://man.archlinux.org/man/kernel_lockdown.7

This could prevent a scenario where a malicious kernel module or access to some interface that kernel lockdown prevents, would allow or assist in escaping the KVM.
It is not very likely as there needs to be an exploitable vulnerability in the hypervisor.
To make it more secure, the host too would need to enable kernel lockdown.

In the end this may only give some sense of security, but, as we all know, that's all that matters anyway.

"Disabling revoked keys in keyring" when running "pacman-key --populate"
is very slow (easily +20 seconds), in our case the boot is now ~27
seconds faster (tested on secure-runner1). The pacman master private key
is removed to prevent malicious actors from injecting packages, a new
key is generated by pacman-init.service on boot.

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

Upstream now provides a solution for setting the "staging dir" for
fastzip[1].

[1] https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3130

For some workloads running in a container is too restrictive, ex:
arch-boxes (loop device, filesystem mount, pacstrap) and archiso
(pacstrap). Currently they both run a TCG accelerated QEMU VM, which is
very slow and painful to work with. We should provide a better option to
our users!

This adds a hardware accelerated VM for this kinds of workloads, which
is way faster and you can do whatever you like (mostly)!

Fix #283

The arch-iso project uses QEMU for building and it uses a lot of memory
(they have crashed runner2 twice), so let's see if we can avoid that by
capping Docker's memory.