[FR] Native (exponential) latency histogram in built-in Prometheus metrics

[nshopik]

Current behavior

Unbound records response times in a fixed 40-bucket, factor-2 (log2) histogram
coarse in the range that matters and wasted in its top buckets above ~8 seconds.

Describe the desired feature

Add a native / exponential histogram alongside the existing log2 one. The
built-in Prometheus metrics keep emitting the current histogram as-is; in
addition, expose the latency distribution as a Prometheus native histogram
(same model as the OpenTelemetry exponential histogram: boundaries at
2^(i / 2^schema), and schema n boundaries are a subset of schema n+1, so
resolution downscales losslessly). Running both in parallel for a transition
period allows existing setups to continue unchanged.

A native histogram picks resolution from a single factor:

factor	schema	buckets/octave	worst-case quantile error
2.0	0	1	100%
1.189	2	4	19%
1.0905	3	8	9%
1.0443	4	16	4.4%

Suggested default: schema 3 or 4 (CoreDNS use 4). Storage requirements if the range is trimmed to DNS latencies:

range	octaves	schema 2	schema 3	schema 4
1µs … 14.7 days (current span)	40	160	320	640
100µs … ~13s	17	68	136	272

Potential use-case

Operators can extract accurate p95/p99 percentiles for SLA dashboards and alerting,
while existing setups continue to work via the parallel classic histogram.

Refs: util/timehist.c / util/timehist.h; PR #1426 (Add prometheus metrics);
Prometheus native histograms / OpenTelemetry exponential histograms (2^(2^-n)).