feat: TLS listener support in the Memcached CR

[berendt]

Why

The current Memcached CR (consumed e.g. from C5C3/forge at deploy/flux-system/infrastructure/memcached.yaml) only exposes replicas and image. Pods serve plaintext on TCP 11211, with no SASL or TLS.

For the OpenStack control-plane in C5C3/forge, the Keystone API ↔ Memcached path is currently the only fully unencrypted backend traffic (MariaDB will gain TLS via the mariadb-operator; OpenBao already runs HTTPS). Without operator support, projects have no upstream-blessed way to enable TLS even though memcached itself supports it.

Background

Upstream memcached supports TLS since 1.5.13 (./configure --enable-tls, runtime flag --enable-ssl plus -Z/-o ssl_chain_cert,ssl_key,ssl_ca_cert,ssl_verify_mode). Common Python clients (pymemcache ≥ 4.0, used via dogpile.cache.pymemcache) speak TLS.

Rough scope (to elaborate)

• Extend the Memcached CRD with a spec.tls block:
  • enabled: bool
  • secretRef (cert-manager-style tls.crt/tls.key/ca.crt) or issuerRef so the operator can reconcile a Certificate
  • clientAuth: none|optional|required (mTLS knob → ssl_verify_mode)
• Reconciler:
  • mount the Secret into pods, set the right memcached flags (-Z, -o ssl_chain_cert=…, ssl_key=…, ssl_ca_cert=…, ssl_verify_mode=…),
  • keep the image requirement explicit (TLS-enabled build) — fail validation when tls.enabled is set against an image that lacks TLS.
• Update Service / readiness/liveness probes for TLS.
• Document the consumer side (e.g. dogpile.cache.pymemcache connection options) in README.

Out of scope here

• SASL — separate feature request.
• Cross-cluster gossip / replication.

Downstream

• C5C3/forge will gain a sibling issue tracking the Keystone-side wiring (DSN/cache config, cert-manager Certificate, e2e test) once this lands.