✨ vsphereparavirtual: Support multiple VM Operator API versions

[silvery1622]

What this PR does / why we need it:
Introduce a version-agnostic Hub Type / Hub Interface layer so that CPI business logic is decoupled from any specific VM Operator API version. The correct versioned adapter is selected at startup via the --vm-operator-api-version flag, enabling backward compatibility with Supervisor while supporting v1alpha5.

Which issue this PR fixes (optional, in fixes #(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
N/A — new feature

Special notes for your reviewer:

• The CPI only uses a small subset (~10-15 fields) of the VM Operator API. Hub Types are intentionally minimal.
• The v1alpha2 adapter preserves exact behavioral equivalence with the previous typed-client implementation.
• dynamic.Interface is used instead of typed clients to avoid importing the full VM Operator API scheme into the CPI binary for each supported version.
• The CPI never creates, updates, or deletes VirtualMachine objects. It only reads them for node discovery. The v1alpha2 and v1alpha5 VM clients expose only Get and List.

Release note:
vsphereparavirtual: add --vm-operator-api-version flag (default: v1alpha2) to select the VM Operator API version used when communicating with the Supervisor cluster. Supported values: v1alpha2, v1alpha5.

[silvery1622]

/hold

[silvery1622]

/test pull-cloud-provider-vsphere-verify-fmt

[DanielXiao]

It seems massive code duplication between v1alpha2 and v1alpha5 adapters and providers, is it possible to a use shared generic helper package? In case we need to onboard v1alpha6, we need to implement the same duplicated code

[silvery1622]

It seems massive code duplication between v1alpha2 and v1alpha5 adapters and providers, is it possible to a use shared generic helper package? In case we need to onboard v1alpha6, we need to implement the same duplicated code

The overlap is intentional to a degree: each API version uses distinct generated types from vm-operator/api, so we keep a thin adapter per version that maps to our stable hub types.
We can reduce duplication further by extracting shared dynamic client helpers (list RV="0", GVK on create/update, consistent FromUnstructured error handling) and shared test utilities, without merging the version-specific conversion tables.
A fully “generic” single adapter would either (a) drop typed APIs and map unstructured→hub only, or (b) require codegen; both are larger follow-ups than this PR’s scope.

[silvery1622]

/rebase

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DanielXiao, silvery1622

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [DanielXiao,silvery1622]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[silvery1622]

/retest

[silvery1622]

/unhold