PMM-15248 oplatencies histogram.

[JiriCtvrtka]

PMM-15248

Problem

On MongoDB 8.3 the exporter fails the scrape with
collected metric ... was collected before with the same name and label values
(#1285).
serverStatus.opLatencies.<reads|writes|commands|transactions> exposes its latency buckets as a
histogram array whose boundary field is named micros, not lowerBound:

"opLatencies": { "reads": { "latency": 1234, "ops": 42,
  "histogram": [ { "micros": 64, "count": 16737 }, { "micros": 512, "count": 947 } ] } }

Bucket detection only accepted lowerBound, so these arrays were not recognized as buckets and each element was flattened into mongodb_ss_opLatencies_reads_histogram_micros and mongodb_ss_opLatencies_reads_histogram_count with identical names and labels — a duplicate series that the registry rejects.

The includeHistograms gate had a second, related problem: it matched on the path (histograms), so it could not see the new histogram node at all, and matching on histogram alone would drop every future node that happens to carry that name without holding buckets.

Fix
Recognize the bucket boundary under either lowerBound or micros (both documented as the lower bound of the bucket) and expose both shapes under the existing lower_bound label, so queries and dashboards do not have to know which shape the server used.
Gate includeHistograms on the bucket shape (an array of {bound, count} documents) instead of the node name, so opLatencies.histogram is skipped by default like the other buckets, while non-bucket nodes named histogram/histograms keep being collected. Fields next to the buckets (e.g. mongodb_ss_opLatencies_latency) are unaffected.
Resulting metric, with one series per bucket:

mongodb_ss_opLatencies_reads_histogram_count{lower_bound="64"} 16737
mongodb_ss_opLatencies_reads_histogram_count{lower_bound="512"} 947

Tests
testdata/get_diagnostic_data_8.3.json — a getDiagnosticData reply captured from the MongoDB 8.3.2 instance of #1285, trimmed to serverStatus.opLatencies (the histogram arrays) and serverStatus.metrics.query (the histograms nodes), so both bucket shapes are covered by real server output. It is parsed with bson.UnmarshalExtJSON because encoding/json yields []any instead of primitive.A and would hide everything array shaped.
All histogram tests now gather through a pedantic registry, so duplicate series and inconsistent descriptors fail the test instead of the scrape, and they assert the captured bound/count pairs rather than just the bound set.
New cases: opLatencies buckets do not collide, are skipped by default, are not renamed or duplicated by compatibleMode / the v1 conversions (no op_type series on the buckets), and a non-bucket node named histogram is still collected.

[JiriCtvrtka]

@copilot review

[Copilot]

@copilot review

I reviewed the current PR changes and didn’t find any high-confidence bugs, logic errors, or security issues.

[JiriCtvrtka]

@copilot review

[Copilot]

@copilot review

I re-reviewed the current PR diff and ran focused histogram/opLatencies tests; no high-confidence bugs, logic errors, or security issues were found.