Main Issue:

PIP: #21635

Motivation

The Function Worker publishes its operational metrics through WorkerStatsManager, which writes to the legacy Prometheus registry. The worker also initializes an OpenTelemetry SDK in PulsarWorkerOpenTelemetry, but it is not actually used. Operators who enable OTel metrics get the broker metrics and nothing from the worker.

This PR continues PIP-320 by registering the worker's operational metrics on the meter that already exists, so the new instruments flow through the same OTel exporters as the broker metrics.
The broker made the same move under PIP-264.

Modifications

• Add OpenTelemetryWorkerStats, which registers the worker's operational instruments on the worker meter: second-based duration histograms for schedule, schedule strategy, rebalance, rebalancestrategy, drain, instance start and instance stop, plus observable gauges for instance count, expected instance count, function count and leader state.
• Wire WorkerStatsManager to record each measurement to both the existing Prometheus metric and the new OTel instrument, so existing /metrics scrapers keep working unchanged; the legacy metrics are annotated with @PulsarDeprecatedMetric pointing at their replacement names.
• Read leadership from leaderService::isLeader instead of the WorkerUtils getIsStillLeaderSupplier, which performed a synchronous admin getStats() call on the coordination topic during every metrics scrape.
• Pass the worker's real OpenTelemetry instance into WorkerServer.FilterInitializer instead of
  OpenTelemetry.noop(), so the RateLimitingFilter metrics are exported as well.
• Add opentelemetry-sdk-testing as a test-only dependency and cover the new instruments in
  OpenTelemetryWorkerStatsTest.

Verifying this change

This change added tests and can be verified as follows:

• ./gradlew :pulsar-functions:pulsar-functions-worker:test --tests "org.apache.pulsar.functions.worker.OpenTelemetryWorkerStatsTest"

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment