IPAM operator Integration for allocating IPs

[liwonMS]

No description provided.

[jeanlag1]

Adding description:

Description

This PR integrates IP Address Management (IPAM) into the Cluster API Provider for Azure Stack HCI (CAPH), enabling NIC and load balancer IP allocations to be tracked and managed through Kubernetes-native IPAddressClaim resources.

What this PR does

• Adds a shared IPAM library (pkg/ipam/ipclaim_helper.go) — a reusable 600-line module that manages the full IPAddressClaim lifecycle including creation, status polling, IP extraction, and cleanup. Supports two allocation sources: operator-ipam (allocated by the IPAM operator) and moc-ipam (allocated by MOC, then synced for tracking). Includes a pluggable telemetry interface for operation logging.

• NIC IPAM integration (cloud/services/networkinterfaces/) — Adds IPAMService to the NIC reconciliation flow. Before MOC provisioning, an IPAddressClaim is created for each NIC. After provisioning, MOC-assigned IPs are synced back to IPAM for tracking. Includes IP conflict detection and retry logic (handleIPAddressConflictRetry).

• Load balancer IPAM integration (cloud/services/loadbalancers/) — Adds IPAMService to the LB reconciliation flow, creating IPAddressClaims for frontend IPs and syncing MOC-allocated IPs. Claims are cleaned up on LB deletion.

• Controller and infrastructure updates — Updates VM reconciler, cluster/LB/VM controllers to pass IPAMService through the reconciliation chain. Registers IPAddressClaim and IPAddress types in the scheme (cmd/manager/main.go). Adds RBAC permissions for ipaddressclaims and ipaddresses resources.

• Code quality fixes — Fixes format string warnings in condition reporting across cluster and LB controllers (non-functional, addresses fmt.Errorf style linting).

Why

IPAM integration enables centralized IP lifecycle management across HybridAKS clusters, preventing IP conflicts and providing visibility into IP allocations through standard Kubernetes CRDs.

[nwoodmsft]

This is accurate for the current Azure Local default, but not for all management clusters that leverage CAPH (e.g. for AKS-HCI product the VNET name is provided by the customer). The group name is more predictable (i.e. group name used for management resources, including the vnet). The group name also differs between Azure Local and AKS-HCI, but it is not a customer provided string.

[liwonMS]

a later check checks for the group name. The IPAM is only enabled if the vnet is in the Arc VM Default_Group. Will also enhance the check for Arc VM specific tag on the vnet so we only exercise ipam code when it's Arc VM lnets.