test: precreate cvi for e2e tests

[universal-itengineer]

Description

Migrate e2e tests from per-test VirtualImage/ClusterVirtualImage creation via HTTP sources to a shared set of precreated ClusterVirtualImages that are bootstrapped once before the suite and reused across runs. Also refactors cloud-init configuration into a typed Go struct and removes ~30 duplicated YAML manifests from testdata.

Why do we need it, and what problem does it solve?

• Each test case created its own VI/CVI resources, downloading the same OS images (Alpine, Ubuntu, Cirros, etc.) from external storage over HTTP. This caused redundant downloads of identical images and significantly increased total test execution time.
• Each legacy test (affinity-toleration, disk-resizing, vm-evacuation, vm-migration, vd-snapshots, etc.) maintained its own set of VI/CVI kustomize manifests with nearly identical content, making maintenance harder and creating a risk of drift.
• Cloud-init user-data was defined as raw strings duplicated across different tests, without typing and with OS-specific differences scattered throughout the codebase.

What is the expected result?

1. Precreated shared CVIs: 12 ClusterVirtualImage resources (Alpine UEFI/BIOS, Alpine Perf variants, Ubuntu, Ubuntu ISO, Cirros, Debian, container images, test data) are created once in SynchronizedBeforeSuite. If CVIs already exist in the cluster from a previous run, they are reused without re-creation, making repeated local runs significantly faster.

2. Tests migrated to precreated CVIs: All e2e tests (VM, legacy, blockdevice, snapshot, vmop suites) now create VirtualDisks and VirtualImages via dataSource.objectRef referencing precreated CVIs instead of downloading images over HTTP. Helper functions NewVDFromCVI and NewGeneratedVIFromCVI are added to simplify construction.

3. Removed ~30 duplicated YAML manifests: Per-test VI/CVI kustomize manifests are deleted from testdata directories of affinity-toleration, complex-test, disk-resizing, image-hotplug, vd-snapshots, vm-disk-attachment, vm-evacuation, vm-label-annotation, vm-migration-cancel, and vm-migration.

4. Typed cloud-init configuration: User-data is now generated from a CloudConfig Go struct with OS-specific presets (AlpineCloudInit, UbuntuCloudInit, PerfCloudInit), each with correct package names and service management commands. Covered by unit tests.

5. Controlled cleanup: Precreated CVIs are preserved between runs by default. Deletion is opt-in via the PRECREATED_CVI_CLEANUP=yes environment variable.

6. Removed unused test: Deleted vm/hotplug_pod.go.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

[hardcoretime]

This can be a validation method of CloudConfig. But not required.

[universal-itengineer]

The #cloud-config header is a property of the rendered string, not the CloudConfig struct itself — Render() always prepends it. A Validate() method on the struct wouldn't have access to it. This check is purely a test-level assertion that the pre-rendered constants are well-formed, so I think it fits better here as is.

[hardcoretime]

Should it be parsed into the CloudConfig structure?

[universal-itengineer]

We intentionally parse into map[string]interface{} to verify actual YAML key names (which are controlled by the struct's json: tags via sigs.k8s.io/yaml). A round-trip through CloudConfig would always be self-consistent and wouldn't catch a tag typo that breaks the cloud-init contract.

[hardcoretime]

Should this file be placed in the precreatedcvi package or cviManager in the object package?

[universal-itengineer]

I don’t think so, because it’s a data/definition file, not a lifecycle file.
The precreatedcvi package's role is solely orchestration