Add DNSZone, DNSZoneShare, and RecordSet controllers for Designate support - #955

Summary

Closes #954. Adds Designate DNS support: DNSZone (zone CRUD, with the projectID-in-status gap
from #825's review fixed), a new DNSZoneShare resource for Designate's zone-sharing API, and
RecordSet for individual DNS records within a zone.

Design question for maintainers: Share vs Transfer

Designate has two separate mechanisms for giving another project access to a zone:

• Zone Transfer (transfer_requests/transfer_accepts) - moves full ownership, needs two
  different projects' credentials in one flow (owner creates the zone + transfer request,
  recipient accepts). Same two-credential shape already raised in Enhancement: Glance image member sharing (grant + accept) #948 for Glance image sharing.
• Zone Share (zones/{id}/shares) - grants another project co-management rights over a
  zone's recordsets while the original project keeps ownership. Single credential only.

DNSZoneShare implements Share, not Transfer, deliberately - it's dramatically simpler (one
credential, no accept-side resource needed, same shape as the RBACPolicy controller for Neutron
network sharing), and we think it's the more broadly useful mechanism to support first. We
confirmed Zone Share is a real, working API on our own OpenStack deployment (a live
create/list/delete round-trip, not just reading the gophercloud bindings) before committing to
this design. Transfer could be a follow-up matching the #948 pattern if there's demand for it.

Architecture notes

• All three resources share one osclients.DNSClient (the "one service, one client" convention
  NetworkClient already established for Neutron), rather than a dedicated client per kind.
• DNSZoneShare and RecordSet are both zone-scoped sub-resources in Designate's own API
  (Get/Create/Delete/Update all require the zone ID alongside the resource's own ID),
  which doesn't fit the generic actuator interfaces' single-ID GetOSResourceByID signature
  directly. Resolved by having each actuator resolve its owning zone once at construction time
  and reuse that across every method call on the same instance, rather than re-resolving per call.
• DNSZoneShare has no update operation at all in Designate's real API (confirmed via
  gophercloud - only List/Get/Share/Unshare) - both zoneRef and targetProjectID are
  immutable here, unlike RBACPolicy's analogous targetProjectID field.
• DNSZone.spec.resource.name (and RecordSet's) must be explicit and end with a period -
  Designate rejects anything else, and unlike most other resources there's no sensible
  object-name fallback (the ORC object's own Kubernetes name won't have a trailing period).
• Because every Designate zone-share/recordset operation is zone-scoped, importing either kind
  needs a zone reference even when unmanaged (no spec.resource to read zoneRef from) - both
  DNSZoneShareFilter and RecordSetFilter gained a required zoneRef field, resolved via the
  same Dependency/*ImportDependency split ApplicationCredential already uses for
  userRef/userImportDependency. One known gap flagged here rather than silently worked around:
  import.id (a bare OpenStack ID, no filter) isn't supported for DNSZoneShare or
  RecordSet - there's no field anywhere to carry a zone reference in that mode, and Designate
  has no zone-independent way to look up either resource by ID alone. newActuator returns a
  clear Terminal error for this case rather than hanging; happy to hear design ideas if this
  gap matters to someone.

Testing

• Unit tests for the actual mutable-field update paths (DNSZone: description/ttl/masters;
  RecordSet: description/ttl/records - both compared as sets, not positionally).
• Full test/apivalidations suite extended with immutability, required-field, and PRIMARY/
  SECONDARY cross-field CEL validation tests for all three resources.
• KUTTL e2e tests for all required scenarios per resource (DNSZoneShare's update scenario
  deliberately omitted - it has zero mutable fields, and the project's own testing guide says the
  update test is only required "for resources that implement mutability").
• Two Designate behaviors the e2e tests depend on were verified live against a real OpenStack
  deployment rather than assumed from documentation: target_project_id isn't validated against
  Keystone (any string accepted, confirmed via a real openstack zone share create call with a
  garbage value), and an exact-duplicate share on the same zone is rejected but differing by zone
  is fine.
• Caught and fixed a real bug via the full go test ./... run (not just the package under active
  work): a curly/smart quote had snuck into one CEL rule's string literal, which would have made
  the CRD uninstallable on any real Kubernetes API server (controller-gen doesn't validate CEL
  syntax, it just transcribes the rule string - the breakage only surfaced when envtest tried to
  actually install the CRD).
• This is the first K-ORC controller to need Designate, so the e2e workflow's devstack deployment
  never had it enabled - added enable_plugin designate ... + DESIGNATE_BACKEND_DRIVER=bind9
  to .github/workflows/e2e.yaml, same pattern already used for neutron/manila.

Test plan

• go build ./..., go vet ./..., gofmt -l . clean
• go test ./... passes (only unrelated test/e2e, which needs a live kind cluster, fails in
  this environment)
• make generate output committed (CRDs, deepcopy, adapters/controllers,
  applyconfiguration/clientset/lister/informer, mocks, API reference docs)
• KUTTL e2e suite run against a real OpenStack cloud in CI

🤖 Generated with Claude Code