feat: Accept wildcard hostnames once the domain is proven by DNS

[scotwells]

Summary

Services that give every bucket or customer its own subdomain need one load balancer to serve a name like *.s3.example.com, and today any hostname starting with a wildcard is rejected.

A load balancer may now carry a hostname with one leading wildcard label, admitted only once its base or a parent domain is verified by DNS TXT record.

HTTP token proof does not count, since anyone who can serve one name beneath the wildcard can serve the token, and neither does a Datum DNS zone until hosted zone claims (datum-cloud/enhancements#917) settle what a zone proves.

This is behind the certificate service setting, which is off by default, and is stacked on #529 so the subtree reservation is in place before any wildcard is admitted.

API

apiVersion: networking.datumapis.com/v1alpha
kind: HTTPProxy
metadata:
  name: s3
spec:
  hostnames:
    - "*.s3.example.com"

A wildcard whose domain was proven another way is held back, and the hostname says what to do:

status:
  conditions:
    - type: HostnamesVerified
      status: "False"
      reason: UnverifiedHostnamesPresent
  hostnameStatuses:
    - hostname: "*.s3.example.com"
      conditions:
        - type: Verified
          status: "False"
          reason: DNSVerificationRequired
          message: >-
            The wildcard "*.s3.example.com" needs DNS proof that you control
            s3.example.com or a parent domain. Domain "example.com" was
            verified over HTTP, which does not prove control of every name
            beneath it. Publish the DNS TXT record shown on Domain
            "s3.example.com" to prove it.
      dnsRecords:
        - name: datum-custom-hostname.s3.example.com
          type: TXT
          content: 7c1e0d52-3b8f-4a51-a0f6-2f4b6c9d8e11
          purpose: Ownership
          managedBy: User
          state: Missing

The per-hostname Verified condition is new and appears only with the setting on:

Status	Reason	When
True	Verified	a Domain covering the hostname is verified, by DNS for a wildcard
False	PendingVerification	no covering Domain is verified yet
False	DNSVerificationRequired	a wildcard whose covering Domain was proven over HTTP, through a Datum DNS zone, or before the method was recorded
False	WildcardNotSupported	a wildcard on a platform without the setting

The assistant's reason catalog explains both new refusal reasons to customers.

When only a non-DNS proof covers a wildcard, the platform creates a Domain for its base, so the user has a TXT record to publish. A wildcard keeps no grace period, so one that loses its proof stops serving.

A Domain verified with the setting on now keeps the condition for the method that proved it. A verified Domain shows no new verification record, so the portal's verification card stays hidden.

kind: Domain
status:
  conditions:
    - type: Verified
      status: "True"
    - type: VerifiedDNS        # or VerifiedHTTP
      status: "True"
      reason: Verified

Validation errors users hit when creating or updating a load balancer or gateway:

Hostname	Setting off	Setting on
*.s3.example.com	refused as not a valid hostname	admitted
*.com or *.*.example.com	refused	refused, a wildcard must be one leading label before a domain with two or more labels
*.datumproxy.net or a name beneath it	refused	refused, platform wildcards are managed by Datum

Users write the spec. Only the operator writes status and creates the Domain for a wildcard's base. No printer columns change.

Test plan

• A wildcard with HTTP token proof, Datum DNS zone proof, or proof from before the method was recorded is refused, and one with DNS TXT proof is admitted
• The webhook refuses wildcards with the setting off and refuses platform and multi-label wildcards with it on
• Build, vet, lint and the full suite pass locally and in CI
• On staging, adding a wildcard over an HTTP-verified domain creates the base Domain and lists its TXT record

Related to datum-cloud/enhancements#913