[Enhancement] Support authentication for the built-in Prometheus metrics endpoint

Who is this for and what problem do they have today?

AutoMQ operators running either VM/IaaS or Kubernetes deployments who expose the built-in Prometheus pull endpoint to a remote Prometheus-compatible collector.

Today, s3.telemetry.metrics.exporter.uri only configures the Prometheus listener host and port, for example:

s3.telemetry.metrics.exporter.uri=prometheus://?host=0.0.0.0&port=9090

The current implementation starts the endpoint without authentication:

• automq-metrics/src/main/java/com/automq/opentelemetry/exporter/PrometheusMetricsExporter.java
• automq-metrics/src/main/java/com/automq/opentelemetry/exporter/MetricsExporterURI.java

Consequently, any client with network access to the listener can scrape /metrics. Operators must currently rely on network isolation, a local collector, or an externally managed nginx/Envoy proxy.

Why is solving this problem impactful?

Metrics may expose operational metadata and detailed cluster behavior. Deployments with security or compliance requirements need a supported way to prevent anonymous scraping without inventing a different integration for each environment.

The solution should cover both deployment models:

• VM/IaaS: a local collector, a host-level proxy, or an authenticated in-process endpoint.
• Kubernetes: a node/pod-local collector, a sidecar proxy, or an authenticated in-process endpoint.

Additional notes

This issue intentionally does not prescribe the final architecture. The design should evaluate at least these options:

1. In-process authentication using com.sun.net.httpserver.Authenticator.
2. A deployment-level proxy that provides HTTPS, Basic Auth, or mTLS.
3. Keeping the endpoint loopback-only and using a local collector that pushes metrics to the backend.

Relevant implementation details found during the initial investigation:

• AutoMQ currently uses opentelemetry-exporter-prometheus:1.40.0-alpha. Its PrometheusHttpServerBuilder does not expose setAuthenticator(...).
• The underlying Prometheus Java HTTPServer.Builder already exposes authenticator(...) and httpsConfigurator(...).
• OpenTelemetry PrometheusHttpServerBuilder exposes setAuthenticator(...) starting with 1.50.0-alpha. Adopting it would require an aligned OpenTelemetry dependency upgrade and compatibility testing.
• An Authenticator alone does not encrypt traffic. Basic credentials over plain HTTP are insufficient for untrusted networks; HTTPS/mTLS requirements must be decided separately.
• Credentials must not be placed directly in the exporter URI because the URI is logged. Prefer a mounted secret file or an existing secret-provider abstraction, with explicit rotation/reload semantics.

Decision points:

• Supported authentication modes: Basic, Bearer token, mTLS, or a subset.
• Whether TLS is implemented in-process or delegated to a proxy.
• Configuration contract and backward compatibility. Authentication should remain opt-in for existing deployments.
• Credential provisioning and rotation for both VM/IaaS and Kubernetes.
• Whether /, /metrics, and /-/healthy share the same authentication policy.
• Collector configuration and migration from existing unauthenticated port 9090 targets.

Expected acceptance outcomes:

• A documented, supported path exists for both VM/IaaS and Kubernetes deployments.
• An unauthenticated remote client cannot read metrics when authentication is enabled.
• An authorized Prometheus-compatible collector can scrape metrics successfully.
• Secrets are not emitted in logs or stored as plaintext in the exporter URI.
• Existing deployments remain compatible when authentication is not enabled.
• Automated tests cover successful authentication, rejected credentials, endpoint behavior, and shutdown lifecycle.