Generic / multi-provider operator-side database token auth (beyond Azure Workload Identity)

[bmorton]

Background

The operator authenticates its own reachability probe and schema-version
inspection to Postgres. As of the Azure passwordless work (closes #47), the
operator can obtain a Microsoft Entra access token natively in-process via
Azure Workload Identity when a datastore sets sql.azureWorkloadIdentity — see
internal/persistence/azure.go and internal/persistence/sql.go.

This was deliberately scoped to Azure only. The original idea of having the
operator execute a generic passwordCommand (like the server pods and schema
Job do) does not work for the operator because it runs on a distroless image
(gcr.io/distroless/static:nonroot) with no shell.

Goal

Make the operator's own DB token acquisition generic / pluggable so other
providers work without a shell, for example:

• AWS RDS IAM auth (generate a short-lived token via the AWS SDK / STS).
• GCP Cloud SQL IAM auth.
• A generic "read the token from a projected file" mode (provider-agnostic),
  for setups where a sidecar/CSI driver writes a token file the operator can read
  directly in-process (no shell).

Notes / starting points

• internal/persistence/azure.go already defines a small tokenProvider
  interface (Token(ctx, scope) (string, error)) and a defaultTokenProvider.
  A provider-selection mechanism (driven by the datastore spec) could dispatch to
  Azure / AWS / GCP / file-based implementations behind that interface.
• internal/persistence/secrets.go resolves the per-store credential
  (ResolvedCredential) and is where a generic provider config would be plumbed.
• Keep the operator distroless: providers must not shell out.

Related

• Closes-context: Full Azure Workload Identity passwordless auth (operator probe + schema Job) #47 (full Azure Workload Identity passwordless auth).