perf: Decouple metrics HTTP server into a dedicated child process - #6855

Summary

Replace the daemon thread that serves the Prometheus /metrics endpoint with a multiprocessing.Process so that scrape-time aggregation (MultiProcessCollector reads + text serialization) runs with its own GIL, fully isolated from request-serving workers and the Gunicorn master.

Problem

When Prometheus scrapes the /metrics endpoint, the current daemon thread performs:

1. File listing of all .db files in PROMETHEUS_MULTIPROCESS_DIR
2. Reading mmap-backed metric files from every Gunicorn worker
3. Aggregating/merging metrics across workers
4. Serializing to Prometheus text format

All of this runs under the same GIL as the Gunicorn master process. With high metric cardinality (many label combinations), this scrape overhead can cause GIL contention that indirectly affects request latency.

Solution

Move the WSGI HTTP metrics server into a dedicated child process via multiprocessing.Process(daemon=True):

• _run_metrics_server() — new top-level function that serves as the child process entry point. It re-imports prometheus_client for macOS spawn safety and registers SIGTERM/SIGINT handlers for graceful shutdown.
• start_metrics_server() — now spawns a Process instead of a Thread. The function signature and call sites are unchanged.
• Background monitoring threads (resource, freshness) remain in-process because they only write to mmap-backed Gauges — an operation that is fast and does not benefit from process isolation.

Why this is safe