apis/kubevault/v1alpha2: add 9 more VaultServer storage backends

[tamalsaha]

Summary

OpenBao recently restored (or is in the process of restoring) a number of physical storage backends that had been removed upstream: CockroachDB, Cassandra, ZooKeeper, CouchDB, MSSQL, Google Cloud Spanner, Aerospike, OCI Object Storage, and Alicloud OSS. VaultServer.spec.backend (BackendStorageSpec) only covered a subset of what OpenBao/Vault actually support (inmem, etcd, gcs, s3, azure, postgresql, mysql, file, dynamodb, swift, consul, raft) — this PR adds the remaining 9 as new optional fields.

Each new spec type follows the existing conventions: *core.LocalObjectReference credentialSecretRef for credentials, DatabaseRef for KubeDB-managed databases where the backend is DB-connection-based (CockroachDB), haEnabled/haTable string pairs for the backends that support HA (CockroachDB, Spanner, and — already supported — OCI in the operator's future validation logic), and tlsSecretRef for backends needing a TLS client cert (Cassandra, ZooKeeper).

FoundationDB is intentionally excluded — it requires CGo and the native libfdb_c client library, so it isn't compiled into standard OpenBao/Vault images and can't be assumed available in a generic VaultServer deployment. Documented in a comment on BackendStorageSpec.

Scope note: v1alpha2-only, not mirrored to v1alpha1

These 9 backends are added to v1alpha2 (the storage/hub version, +kubebuilder:storageversion, and the only version the operator's pkg/vault/storage package actually consumes) but not mirrored into v1alpha1. v1alpha1's existing backend spec types (PostgreSQLSpec, MySQLSpec, ...) predate several v1alpha2-only conventions the new types also use (SecretRef-typed credentials instead of bare secret-name strings, DatabaseRef, HAEnabled) — a 1:1 mirror isn't mechanical here the way it was for e.g. Swift/Consul/Raft, it would need bespoke field-mapping Convert_v1alpha1_<X>Spec_To_v1alpha2_<X>Spec functions per backend (see the existing pattern in apis/kubevault/v1alpha1/conversion.go). Left as a documented, deliberate follow-up rather than done half-carefully in this PR.

Codegen

Regenerated zz_generated.deepcopy.go and crds/kubevault.com_vaultservers.yaml with locally-installed deepcopy-gen/controller-gen (v0.33.5/v0.16.5 respectively — not the repo's ghcr.io/appscode/gengo:release-1.32 Docker image, which wasn't practical to pull in my environment). Before making any changes, I ran both tools against the unmodified tree and confirmed byte-for-byte (deepcopy) / near-byte-for-byte (CRD, modulo a controller-gen.kubebuilder.io/version annotation this repo's pipeline apparently strips) parity with what's already committed, then applied the same kubectl patch/kubectl label post-processing make patch-crds/make label-crds do. The CRD diff is purely additive (616 lines, all +) against the committed file.

openapi_generated.go was not regenerated — its pipeline (dockerized openapi-gen + hack/gencrd/main.go) wasn't reproduced locally. This only affects generated OpenAPI/swagger schema docs, not runtime behavior; happy to follow up if that's needed before merge.

Companion PRs

• kubevault/operator: wires these into pkg/vault/storage's factory + the VaultServer validating webhook (depends on this PR being merged/tagged first, or a replace directive during review).
• kubevault/kubevault: adds concept docs for each new backend.