[2316] Feature: Add Hitachi support for storage accelerated migration via cinder mediated LUN Mapping

[spai-p9]

What this PR does / why we need it

Adds Hitachi Vantara (VSP family) as a third array vendor for Storage-Accelerated Copy (XCOPY), alongside the existing Pure and NetApp providers. Unlike Pure/NetApp, Vantara's Cinder driver (HBSD) already owns host/initiator-group/LUN-map management, so instead of reimplementing that against Hitachi's Configuration Manager REST API, this PR splits StorageProvider into a core surface + an optional VendorMapper surface, and adds a Cinder-mediated mapping fallback (os-initialize_connection/os-terminate_connection) that any vendor without native mapping can use.

Why the interface split

Previously StorageProvider bundled volume CRUD and ESXi host/initiator-group/LUN mapping into one interface, which implicitly assumed every vendor manages mapping through its own array API (true for Pure and NetApp, not true for Hitachi).

• StorageProvider (required) — volume create/delete/info/NAA, ResolveCinderVolumeToLUN, WhoAmI.
• VendorMapper (optional, type-asserted) — CreateOrUpdateInitiatorGroup / MapVolumeToGroup / UnmapVolumeFromGroup. Pure and NetApp implement this unchanged.
• New optional interfaces providers can mix in:
  • CinderManageRefBuilder — non-default manage_existing reference (Hitachi needs {"source-id": }, not the default {"source-name": ...}).
  • CinderBackendPoolAware — derive volume placement (Hitachi DP pool) from the Cinder backend/pool already configured on ArrayCreds.
  • PostMappingNAAResolver — for vendors (some Vantara firmware) where the LDEV's naaId isn't populated until after the LUN is mapped to a host, so NAA must be resolved post-mapping instead of trusted from CreateVolume.

Cinder mapping fallback (pkg/vpwned/sdk/storage/cinder)

New CinderMapper implements the same three mapping operations by driving the array's own Cinder driver via os-initialize_connection/os-terminate_connection with an os-brick-style connector built from the ESXi host's HBAs — instead of calling array-native host/initiator-group/LUN-map APIs. Volume create/delete/NAA/resolve stay vendor-native regardless of mapping mode, since creating the LUN through the array's own REST API is what pins it to the correct physical array/pool.

Selection is controlled by a new ArrayCreds.spec.mappingMode:

• auto (default) — vendor-native mapping if the provider implements VendorMapper, else Cinder fallback
• native — hard-require vendor-native mapping (fails validation otherwise)
• cinder — force the Cinder fallback even for Pure/NetApp (useful for testing the fallback path itself)

v2v-helper (migrate/mapper.go) adds a Mapper interface + selectMapper() that adapts vendor-native providers (ctx-less by design) into a ctx-aware wrapper, and picks between vendorMapperAdapter and CinderMapper per this mode.

Hitachi Vantara provider (pkg/vpwned/sdk/storage/vantara)

New provider implementing only the core StorageProvider surface against Hitachi's Configuration Manager (GUM/SVP) REST API: session auth (~30 min expiry, auto re-auth at 25 min), async job polling, LDEV create/delete/info, and NAA lookup. It does not implement VendorMapper — mapping always goes through CinderMapper/HBSD.

Also includes:

• d17de1e — auto-detection of Vantara as the array vendor
• 79380ca — auto-discovery of the Cinder volume backend/pool for Hitachi
• a34d4a3 — wait/retry for LDEV discoverability post-mapping
• 0790ca0 — resolve NAA via LDEV lookup (implements PostMappingNAAResolver) since naaId isn't populated until the LDEV is host-mapped
• 21c43da/45ba60b52 — correct Cinder volume-type resolution for Hitachi backends, falling back to empty rather than a wrong guess when it can't be determined confidently

API/CRD changes

• ArrayCredsSpec gains MappingMode (enum: auto/native/cinder) and VantaraConfig (PoolID, RESTPort)
• Regenerated deepcopy + CRD YAML (make generate)

UI

• Added Hitachi Vantara to array credentials add/edit forms (ArrayCredentialsFormFields.tsx, drawers), matching the pattern used for NetApp's SVM/FlexVol fields

Testing

• pkg/vpwned/sdk/storage/vantara/vantara_test.go — provider unit tests (534 lines)
• pkg/vpwned/sdk/storage/cinder/mapper_test.go — Cinder fallback mapper tests (280 lines)
• v2v-helper/migrate/mapper_test.go — mapper selection logic (235 lines)
• k8s/migration/pkg/utils/backendpools_test.go — backend pool resolution (195 lines)
• migrationplan_controller_test.go — new cases for MappingMode/VantaraConfig plumbing
• ui/src/api/array-creds/arrayCreds.test.ts — UI round-trip for new fields

Notes for reviewers

• specs/005-cinder-mapping-fallback/ contains the design doc (spec/plan/research/data-model/contracts) this PR implements, if useful for context on the interface split rationale.
• No changes needed to pkg/vpwned/upgrade/* (Constitution Principle X) — no new Deployment/image/manifest introduced.
• No changes needed to the Migration Form four-surface parity (Principle VIII) — this is array credentials, not a migration field.

Which issue(s) this PR fixes

(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged)

fixes #2316

Special notes for your reviewer

Testing done

please add testing details (logs, screenshots, etc.)

[github-actions]

✅ Security Vulnerability Summary

No change in security posture

📊 Overall Changes

Metric	Count
Total Added	0
Total Fixed	0
Net Change	0

🔍 Detailed Breakdown

📦 Gosec (Static Analysis)

Current	Baseline	Added	Fixed	Method
0	0	0	0	artifact

📦 Trivy (Dependency Scan)

Current	Baseline	Added	Fixed	Method
95	95	0	0	artifact

📋 Baseline Methods

• 📦 artifact: Used stored report from main branch
• 🔄 live_scan: Scanned base branch in real-time
• ⚠️ no_baseline: No baseline available (all vulnerabilities treated as new)

---

Only HIGH and CRITICAL severity vulnerabilities are tracked
Baseline: f2395c5a040f6a6260b681334f9430a75389e100