VPC/Kubernetes/KubernetesNodes: model the Proxmox-backed VPC subnet fields (upstream cozystack#4813) #66

Context

cozystack/cozystack PR #4813 (draft; design proposal cozystack/community#93, parent issue cozystack/cozystack#3481) lets a VirtualPrivateCloud subnet be backed by a Proxmox VLAN, so Proxmox VMs, including the workers of a Proxmox-backed tenant cluster, attach to the same L2 as the VPC's pods. It adds these optional fields:

KubernetesNodes proxmox.network.bridge is no longer required when vpc/subnet are set.

Things worth care in the model

• subnets[].proxmox is presence-based. The chart treats a subnet as Proxmox-backed when the proxmox key is present and is a map, so proxmox = {} (zone and range defaulted) is a different request from proxmox being absent. A model that drops an empty nested object silently turns a Proxmox-backed subnet back into an overlay subnet, which deletes its VLAN and IP pool. Same family as KubernetesNodes: model the new image field (upstream cozystack#3294) #39 (image.builtin = {}).
• Mutually exclusive inputs are rejected at render. KubernetesNodes proxmox.network.vpc/subnet cannot be combined with bridge/vlan, and Kubernetes proxmox.network.vpc/subnet cannot be combined with proxmox.ipv4Config.addresses. Empty strings and a zero VLAN are treated as unset, so the provider must not send real defaults for the fields it does not own.
• additionalNetworks[].mtu should stay null when unset. Unset means "use the zone's MTU".
• Do not marshal the upstream vpc.Subnet type to build the spec. In the feat(vpc,kubernetes): back VPC subnets with Proxmox VLANs cozystack#4813 head the generated Subnet.Proxmox is a struct value (SubnetProxmox, json:"proxmox,omitempty"), not a pointer, and omitempty does not drop a struct, so marshalling vpc.Subnet emits proxmox: {} for every subnet and would make each one Proxmox-backed. Keep building the map by hand, as the provider does today, and send proxmox only when the configuration has the block. The type may change before the PR merges.
• allowSubnets is refused on a Proxmox-backed subnet. It lives on the same subnets[] object and is tracked in vpc: support subnets[].allowSubnets #61.

Dependencies

• The fields nest under the substrate/proxmox blocks that feat(kubernetes): add a proxmox substrate for managed clusters and worker pools cozystack#4088 added to Kubernetes and KubernetesNodes (first shipped in v1.7.0-alpha.2). The provider does not model those blocks yet, and the pinned api/apps/v1alpha1 module (v1.6.3) does not have them, so they need to land first or together with this.
• The spec-coverage guard (assertSpecCoverage) reflects against the pinned module, and feat(vpc,kubernetes): back VPC subnets with Proxmox VLANs cozystack#4813 is not in a release. This should wait for the upstream PR to merge and ship in a tagged release, then bump the api/apps/v1alpha1 pin to pick up vpc.SubnetProxmox, vpc.Egress, kubernetes.ProxmoxClusterNetwork, the new kubernetesnodes.ProxmoxNetwork fields and kubernetesnodes.ProxmoxAdditionalNetwork.

Why this repository is affected

Per the upstream trigger map (docs/agents/contributing.md, "Downstream Repositories"), this provider models every app field by hand (internal/provider/vpc_schema.go, vpc_model.go, kubernetes_* and kubernetes_nodes_*). Until the fields are modelled they cannot be set from Terraform. Because an update replaces the whole spec, an apply against an object that declares them through the API also strips them, which for subnets[].proxmox removes the subnet's Proxmox VLAN.

Assisted-by: LLM