Pinot Broker: Add fail-open routing observability metrics - #19891

Minor: most recently added meters here carry a /// Javadoc explaining exactly when they are emitted. These two have non-obvious semantics worth documenting the same way: FAIL_OPEN_ELIGIBLE_SEGMENTS is a transition counter (it fires once when a segment enters the unavailable-with-candidates state, not per refresh), while FAIL_OPEN_ELIGIBLE_REQUESTS fires once per query that touches such a segment. Spelling that out will save operators from misreading the rates.

Minor/nit: the phrase "Panic routing" doesn't appear anywhere else in the codebase — the rest of the code calls this "fail-open". Using the same term consistently here would make it easier to grep and reason about.

Minor: this public constructor silently defaults segmentsWithoutCandidates to the full unavailableSegments set, which means any SegmentStates built this way treats every unavailable segment as having no candidates (so it never counts as fail-open eligible). That's a safe/conservative default, but it's surprising — a short comment explaining the intent would help future callers, since production now always uses the 4-arg form.

[P2] Distinguish failure-detector exclusions from administrative disables.

A nonempty candidate list does not establish the eligibility described in the PR's testing section. The supplied enabled-instance set excludes servers with HELIX_ENABLED=false, QUERIES_DISABLED=true, or shutdown in progress, as well as failure-detector exclusions. If all replicas are administratively disabled while IS/EV remain ONLINE, both new meters count them as fail-open eligible. Please carry the exclusion reason into this classification and require at least one candidate that is still administratively enabled but excluded by the failure detector. A routing-manager test contrasting these cases would cover the distinction.

[P2] Emit segment transitions only from the main table selector.

BaseBrokerRoutingManager creates a separate selector for each configured table sampler, using the same table name and BrokerMetrics, and updates all of them on instance changes. A segment included in N samplers therefore increments this meter N+1 times for one transition. The main routing entry should own table-level emission, following the existing replica-health reporting approach. An overlapping-sampler test would catch this. The transition count can also be accumulated during the existing old-segment loop and emitted once, avoiding the extra pass and repeated meter calls.

[P2] Count eligible requests before subclass selection can throw.

The protected select(...) call at line 596 runs before this increment. For multiStageReplicaGroup, an old segment whose ONLINE IS/EV candidates are all excluded has no enabled candidate list, and MultiStageReplicaGroupSelector.assign() throws before reaching this meter. The segment meter increments, but affected requests are omitted. Classify and record eligibility from the captured snapshot before invoking subclass selection, preserving the existing exception behavior. The new test's selectorType provider does not include this selector.

[P2] Deduplicate request counts across scans of the same physical table.

This increments once per select invocation, while the meter documents once per query per physical table. Both MSE planners route separate leaf scans independently. A non-partitioned self-join with distinct leaves that both touch an eligible segment can therefore increment twice for the same request and physical table. Aggregate eligibility in request-scoped state and emit once per physical table; a self-join regression with distinct leaf filters would cover this.

Simplification: store _failOpenEligibleSegments directly here. Both consumers currently reconstruct eligibility as unavailable minus candidate-less, which introduces compound conditions and negation. An explicit eligible set lets transition detection use !previousEligibleSegments.contains(segment) and request classification use eligibleSegments.contains(segment). The existing three-argument constructor can default it to Set.of(), preserving its conservative behavior. Keep the set in this same published snapshot so routing and eligibility stay consistent.