Convert OEM packages to sysext, drop several images, revamp Vagrant support

[chewi]

Brace yourselves, this is a big one! The good news is the difference is about -1600 lines. 😁

Since having the OEM sysext packages built in the "packages" job, they have been ecleaned and then built again later. This fixes that issue and ensures they are always consumed from binary packages.

This drops the per-OEM USE flags. Having a USE flag per OEM is unnecessary when we only really need to know whether the package will be installed in an OEM sysext or not. A single USE flag could do this, but our existing flatcar_target() helper avoids the complexity of binpkg-multi-instance. The flag names were also prone to conflicts (e.g. qemu) and we don't currently make use of them anyway.

This populates the SYSEXT_ID/NAME/VERSION_ID/HOME_URL/BUG_REPORT_URL extension-relhease.d fields in each sysext. These are equivalent to their non-SYSEXT os-release counterparts. Most of these are taken from the sysext's package is it is built from just one, which is often the case. These fields are now used to write the oem-release file later by extracting them with systemd-dissect.

As per flatcar/bootengine#124, this adds the vboxguest kernel module, which allows the VirtualBox image to actually boot. It broke when upstream Ignition changed how the VirtualBox support works.

Also per flatcar/bootengine#124, the Ignition patch to handle unsupported platforms like Vagrant has been dropped because it is more useful to rely on systemd-detect-virt than to simply assume "metal", which does nothing.

As with my other recent PRs, this drops support for Equinix Metal (Packet) and Rackspace. It also drops the vmware_insecure image, which seems pointless, the vagrant_virtualbox image, which is unneeded when the vagrant image already targets VirtualBox, and the vagrant_vmware_fusion image, which we haven't actually built for years.

Dropping vagrant_virtualbox also meant dropping support for that combination in Afterburn. Now that the OEM ID is just vagrant, we can't distinguish it from Parallels. I highly doubt anyone cares, and it brings up closer to upstream.

The main point of this whole PR is to convert the remaining OEM packages to sysexts. This involves reworking how they are built. common-oem-files was a giant hack. oem-release is now generated from the sysexts themselves as mentioned above. grub.cfg is often just a couple of lines, so there's no point in having all this complex logic around generating it, especially when that logic has some exceptions anyway. It's far easier to just explicitly store each variant under build_library/oem. The list of OEMs is now generated by looking for coreos-base/oem-*/*.ebuild.

This totally revamps our Vagrant support, dropping custom code that was merged upstream years ago, adding support for Ignition and cloud-config within the single VirtualBox image, and sharing the JSON metadata between the VirtualBox and Parallels images. Check flatcar/flatcar-website#567 to see what this new support looks like in practise.

The VirtualBox OVF, which is also used by the Vagrant image, has been modernised for new hardware, including a VirtIO storage controller and UEFI. VirtualBox actually uses EDK2 for UEFI.

This drop the OEM sysext dependencies from coreos-devel/board-packages because these are no longer necessary now that they explicitly built with --onlydeps in build_sysext_packages().

This needs to be merged in conjunction with flatcar/bootengine#124 and flatcar/coreos-cloudinit#38.

How to use

There's obviously a lot to unpack here. You can try VirtualBox and Vagrant with my build using the new docs in flatcar/flatcar-website#567.

Testing done

Jenkins completed successfully, except for Digital Ocean, which is unrelated. There are surprisingly few resulting image differences for such a large change. I have obviously done loads of manual testing around this, especially with VirtualBox and Vagrant. Unfortunately, I don't think we have the means to test the other OEMs being migrated, namely CloudSigma, CloudStack, and Exoscale, but I think these are all community supported.

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.