Always create VMs with `qcow2` disks

[comps]

ComplianceAsCode/content#14520 proved that GUI installations do indeed use a LOT of disk space, much more than a decade ago (when ~2-3 GB were enough).

Changing from raw to qcow2 does have a negative performance impact, but if the image is created with preallocation=metadata, the file uses a few more MBs, but is a lot faster. Not as fast as raw, but it's Good Enough.

Theoretically, this should be as easy as changing disk_format= to qcow2 as function argument defaults, alongside with an increase in image size to ie. 100 GB.

This would be "virtual space" for kickstarts to use, the real qcow2 file size would be under ~10 GB (fits easily within our 40 GB outer VMs), but it would give a lot of extra headroom for all the partitions created by kickstarts which then wouldn't need to neatly fit within 20 GB, with us guessing where the real usage is, adjusting partition sizes all the time.

It would also allow us to drop the STIG /usr hack because now there would be easily enough (virtual) space.

[comps]

Actually, it seems virt-install cannot pass the preallocation=metadata flag to qemu-img.

So we would need to split the current

'--disk', f'path={disk_path},size=20,format={disk_format},io=native,cache=none',

into two commands:

['qemu-img', 'create', '-f', disk_format, '-o', 'preallocation=metadata', disk_path, '20G']

['virt-install', ......, '-disk', f'path={disk_path},format={disk_format},io=native,cache=none', ......]

But that should be easy.