[fix][broker] Run topic policy notifications on the topic-ordered executor

[lhotari]

Main Issue: #26037

Motivation

Topic-policy listener callbacks (TopicPolicyListener.onUpdate, i.e. PersistentTopic.onUpdate →
applyUpdatedTopicPolicies) were invoked synchronously on the system-topic policies reader's completion
thread. That reader runs on the broker's internal Pulsar client, whose internal executor is a single,
process-wide shared thread (broker-client-shared-internal-executor, new ExecutorProvider(1, ...)), shared
by every broker-client instance.

Because onUpdate performs non-trivial — and potentially blocking — work, running it on that single shared
thread serializes and can stall topic-policy loading for all namespaces. As reported in #26037, a single
topic whose oldest ledger is temporarily inaccessible could delay policy loading across the broker.

Modifications

• Centralize the topic-to-thread mapping. BrokerService#getTopicPoliciesNotifyThread(TopicName) resolves
  the single, deterministically-chosen "policies notify" thread for a topic
  (topicOrderedExecutor.chooseThread(topicName)). A partitioned topic name is resolved to its base topic so
  that all partitions of a topic share one notify thread. Both AbstractTopic and
  SystemTopicBasedTopicPoliciesService go through this one method, so the topic→thread mapping cannot
  accidentally diverge.
• Dispatch topic-policy notifications off the shared reader thread. SystemTopicBasedTopicPoliciesService
  notifies listeners on the per-topic notify thread (live updates), and during cache initialization replays
  per-topic notifications in parallel on that executor instead of serially on the reader thread. Keying by
  topic preserves per-topic notification ordering, and dispatch is skipped when a topic has no registered
  listeners.
• Pin each topic to its notify thread and apply all policy paths on it. AbstractTopic resolves and stores
  its notify thread once in the constructor, and the policy-application paths run on it consistently:
  • PersistentTopic#initTopicPolicy / #initialize and NonPersistentTopic#initialize apply the initial
    policies on the notify thread.
  • BrokerService dispatches both namespace-policy updates (onPoliciesUpdate) and local-policy updates
    (PersistentTopic#onLocalPoliciesUpdate → checkPersistencePolicies) on the topic's notify thread, so all
    policy mutations for a topic are serialized on the same thread.
• In unit tests that build a topic with a mock BrokerService, getTopicPoliciesNotifyThread returns null;
  the constructor simply stores it (the thread is unused in those tests), so no stubbing is required and
  production behavior is unchanged (a running broker always has the executor).

Verifying this change

This change is covered by existing tests and adds one regression test:

• SystemTopicBasedTopicPoliciesServiceTest — adds testListenerNotificationRunsOffSharedReaderThread, which
  asserts that listener.onUpdate runs on the topic-ordered executor (broker-topic-workers) rather than the
  shared broker-client-shared-internal-executor reader thread. The partitioned-topic notify path is exercised
  by testListenerCleanupByPartition.

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

• The threading model

Topic-policy listener notifications and policy application (namespace and local policies) now run on the
per-topic ordered executor instead of synchronously on the shared broker-client reader thread.