Decouple topic/namespace/tenant names from internal identifiers in Pulsar

[AvaneeshPothuri]

Problem

Pulsar uses the user-given name directly as the internal identifier
via the FQN (persistent://tenant/namespace/topic). This name drives:

• ZooKeeper path construction
• Namespace bundle hash → broker assignment

This makes renaming impossible. Changing the name changes the hash,
changes the bundle, breaks broker routing.

Proposed idea

Pulsar generates stable internal IDs for tenant, namespace, and topic
on creation. The user-given name is stored as metadata (e.g. in the
managed ledger blob's properties field or equivalent).

Flow:

1. User creates topic with name txn-events
2. Pulsar generates an internal ID (e.g. t3, ns7, tp42)
3. FQN becomes persistent://t3/ns7/tp42 — this is what drives hashing
   and ZK paths, never changes
4. txn-events is stored as display metadata against tp42
5. Pulsar returns the ID to the user for use in producer/consumer config
6. All display surfaces — logs, admin UI, metrics, CLI output — resolve
   the ID back to the human name from metadata

Renaming

Renaming = update the name metadata on the ID. ID doesn't change,
hash doesn't change, broker assignment doesn't change. Zero disruption
to producers/consumers already connected.

Similarity to Kafka's KIP-516

Kafka introduced UUIDs as internal topic identifiers (KIP-516) for
similar reasons. This proposal takes it further — making the ID the
primary handle for users too, with names purely as display metadata.

Tradeoffs worth discussing

• Producers/consumers use IDs in their config, not human names.
  Is this acceptable UX or does Pulsar need a name→ID resolution
  layer so users can still connect by name?
• ID generation strategy — auto-increment, UUID, or hash-based?
• Migration path for existing topics already using name-based FQNs

Questions for the community

• Is there real motivation or use cases in the community for this direction?
• Any prior discussion on this I may have missed?
  (Closest I found: https://codingthestreams.com/pulsar/2022/10/21/possible-high-level-architecture.html
  — proposes name→ID indirection internally, but as part of a larger rearchitecting effort)