refactor: migrate metrics from prometheus crate to metrics-rs facade

[shuheiktgw]

Description

Replace the prometheus crate with the metrics-rs facade so a single call site can fan out to Prometheus, OTLP, and DogStatsD. A FanoutBuilder in logger.rs composes the three recorders and a PrefixFilter routes quickwit_* to Prometheus + OTLP and pomsky.* to DogStatsD.

Histogram-only static registration via inventory

metrics-rs does not expose bucket configuration through the Recorder trait — the Prometheus and OTLP exporters need bucket bounds configured up-front, before any observation. To avoid a full metric-registry refactor, histograms only are declared statically: new define_histogram! / define_histogram_vec! macros register a HistogramConfig via inventory at compile time, and the install path walks inventory::iter::<HistogramConfig>() to apply bounds to both exporters.

Counters and gauges continue to use the existing runtime new_counter* / new_gauge* helpers. Per discussion with @fulmicoton, migrating them to the same static style is out of scope for this PR.

Breaking change: gRPC metric naming

GrpcMetricsLayer::new(subsystem, kind) previously baked subsystem into the metric name (quickwit_<subsystem>_grpc_requests_total, ...). Since histograms now require a compile-time-fixed name, the subsystem is extracted into a dynamic service label on a single metric family:

quickwit_grpc_requests_total{service=..., kind=..., rpc=..., status=...}
quickwit_grpc_requests_in_flight{service=..., kind=..., rpc=...}
quickwit_grpc_request_duration_seconds{service=..., kind=..., rpc=..., status=...}

[Mallets]

You don't really need to have two macros: define_histogram and define_histogram_vec.

You can have a single macro accepting a variable number of arguments, e.g.:

macro_rules! define_histogram {
    (  $static_name:ident,
        name: $name:literal,
        help: $help:literal,
        subsystem: $subsystem:literal,
        buckets: $buckets:expr $(,)?
    ) => {
        // Do stuff to define the histogram
    };
    (  $static_name:ident,
        name: $name:literal,
        help: $help:literal,
        subsystem: $subsystem:literal,
        buckets: $buckets:expr $(,)?,
        const_labels: [$(($ck:literal, $cv:literal)),* $(,)?],
        labels: [$($label:literal),+ $(,)?],
    )=> {
        // Do stuff to define the histogram with labesl
    };
}

You can think about it like it was match statement run at compile time based on the number/types of arguments.

[Mallets]

To improve the readability of the whole codebase, I think it's better if the macro returns the Histogram directly without declaring the static and LazyLock internally.

This makes the macro more portable outside the static context. The histogram definition than becomes a usage pattern in the codebase rather than a constraint of the macro.

E.g.:

quickwit_common::define_histogram! {
    THREAD_UNPARK_DURATION_MICROSECONDS,
    name: "thread_unpark_duration_microseconds",
    help: "Duration for which a thread of the main tokio runtime is unparked.",
    subsystem: "cli",
    buckets: quickwit_common::metrics::exponential_buckets(5.0, 5.0, 5).unwrap(),
}

would become:

static THREAD_UNPARK_DURATION_MICROSECONDS: LazyLock<Histogram> = LazyLock::new(|| quickwit_common::define_histogram! {
    name: "thread_unpark_duration_microseconds",
    help: "Duration for which a thread of the main tokio runtime is unparked.",
    subsystem: "cli",
    buckets: quickwit_common::metrics::exponential_buckets(5.0, 5.0, 5).unwrap(),
});

[shuheiktgw]

@Mallets I’ve fixed it, so could you take a look when you have a chance?