Fixes: 3bda5b26 ("Use new experimental VM runners[1] for building")

A VM with KVM acceleration is much faster than TCG, and the current
setup somehow broke again :/

[1] infrastructure!385

The jobs will get stuck as the secure runner is only enabled for the
archlinux group.

The fast-single-thread runner is much faster (test-cloudimg-qemu):
3min 39sec[1] vs 8min 37sec[2]

[1] https://gitlab.archlinux.org/klausenbusk/arch-boxes/-/jobs/14739
[2] https://gitlab.archlinux.org/klausenbusk/arch-boxes/-/jobs/14746

It is similar to the cloud-image but it comes with a preconfigured arch
user (pw: arch) and lacks cloud-init.

Some of our runners is vey slow and building on them takes +1 hour and
we need to adjust many of the timeouts, so let's just build on the fast
runners.

http/install-common.sh:
Order pacman-init.service and reflector-init.service before
cloud-final.service, as the latter may install packages using pacman and
will introduce a broken pacman keyring if started simultaneously with
pacman-init.service.
The mirrorlist should be set before cloud-final.service is running, so
that pacman can use it.

.gitlab-ci.yml:
When testing the cloud image using cloud-init:
* Use the `packages` and `runcmd` directives to install packages using
  cloud-init (which is done during `cloud-final.service`).
* Check for packages installed via cloud-init.
* Write a test file to disk and check for its existence.

Fixes #121

This is helpful for checking out the results of merge requests, for instance.

This will allow us to make multiple releases a day which would be nice for hotfixes and such.

This will allow us to link a release to a file to specific Vagrant Cloud version.

See also https://docs.gitlab.com/ee/ci/metrics_reports.html

Our security concept doesn't allow us to move artifacts built in non-secure environments to secure environments.
This means we'll have to make sure that the boxes we release are built on a runner marked as
'secure'.

Using actual VMs to build VMs is slow and error-prone (you need to use
VNC to see what is going on, and booting takes over +110 seconds as we
wait to be sure Arch Linux is ready).

build.sh can build all three images in ~135 seconds (assuming all the
packages is cached), we still need to use a VM for the actually building
in GitLab CI (as that is the only safe way it can be done at the
moment), which is a bit slower (~22 min vs ~13 min (Packer)), but that
isn't really a big issue.

In the future we can hopefully switch to Kate Containers[1] and reduce
the build time significantly.

[1] infrastructure#108

Kristian Klausen authored Aug 15, 2020 and Sven-Hendrik Haase committed Aug 16, 2020

Fix #108

In my tests, this slows down the builds from 4m to 10m per build BUT allows use build
on public non-kvm-enabled builders which gives us the ability to run random MRs on CI.
Additionally, we can now run many builds in parallel.