feat: support metric name filtering in OpenTelemetry exporter

[subhramit]

Closes the last pending high-priority item in #1816 (as all others have already been addressed).

Currently, PrometheusMetricProducer always exported all metrics in the registry unconditionally. The code already had a TODO sketching how filtering could be added:

client_java/prometheus-metrics-exporter-opentelemetry/src/main/java/io/prometheus/metrics/exporter/opentelemetry/PrometheusMetricProducer.java

Lines 47 to 54 in 9432fdc

	// Note: Currently all metrics from the registry are exported. To add metric filtering
	// similar to the Servlet exporter, one could:
	// 1. Add filter properties to ExporterOpenTelemetryProperties (allowedNames, excludedNames,
	// etc.)
	// 2. Convert these properties to a Predicate<String> using MetricNameFilter.builder()
	// 3. Call registry.scrape(filter) instead of registry.scrape()
	// OpenTelemetry also provides its own Views API for filtering and aggregation, which may be
	// preferred for OpenTelemetry-specific deployments.

this PR implements that by reusing ExporterFilterProperties and MetricNameFilter, as already done by PrometheusScrapeHandler.

As a result, the OpenTelemetry exporter now honors the shared io.prometheus.exporter.filter.* configuration, making its behavior consistent with the HTTP/Servlet exporters.

[subhramit]

cc @zeitlinger :)

[zeitlinger]

The filtering implementation is consistent with PrometheusScrapeHandler: it builds the same MetricNameFilter from all four ExporterFilterProperties fields and uses registry.scrape(predicate). I ran the exporter module test reactor locally and it passed (including all 35 exporter-module tests). The two new tests cover exact-name exclusion and allowed-prefix filtering; please also add coverage through the user-facing configuration path (OtelAutoConfig) rather than only constructing PrometheusMetricProducer directly, so the wiring itself is protected against regression.

[subhramit]

please also add coverage through the user-facing configuration path (OtelAutoConfig) rather than only constructing PrometheusMetricProducer directly, so the wiring itself is protected against regression.

This is also added now.

[zeitlinger]

Could you add a short note to docs/content/otel/otlp.md that the OpenTelemetry exporter now honors the shared io.prometheus.exporter.filter.* metric-name filter properties, with a link to the existing “Exporter Filter Properties” section in docs/content/config/config.md? The property keys are already documented there, so a separate page is not needed.

[subhramit]

Could you add a short note to docs/content/otel/otlp.md that the OpenTelemetry exporter now honors the shared io.prometheus.exporter.filter.* metric-name filter properties, with a link to the existing “Exporter Filter Properties” section in docs/content/config/config.md? The property keys are already documented there, so a separate page is not needed.

Added.

[zeitlinger]

Thanks for addressing the builder API, end-to-end wiring test, and documentation. The filtering behavior now matches the existing scrape-handler path, and CI is green.

[zeitlinger]

Thanks for the contribution!