[fix][broker] Reject topic names with leading or trailing whitespace on creation

[crossoverJie]

Motivation

Creating a topic whose local name has leading or trailing whitespace (e.g. persistent://public/default/test-topic-x ) succeeds via the admin API, but producing to / consuming from it fails with TopicDoesNotExistException when allowAutoTopicCreation=false.

Root cause: Pulsar clients (Java ConsumerBuilder / ProducerBuilder / ReaderBuilder) trim topic names, so the client resolves to the trimmed name while the created znode keeps the whitespace (Codec encodes the space as +). The orphaned topic can never be reached — and can't even be deleted, because the delete path also trims the name and returns 404.

Rejecting on creation is preferred over server-side trimming: trimming would silently reroute non-Java clients (Go/C++/Python, which do not trim) to a different name after an upgrade, and would make already-broken whitespace topics un-deletable.

Modifications

• TopicName: added isValidForCreation(TopicName) and validateTopicNameForCreation(TopicName) — reject leading/trailing whitespace in the local name; internal whitespace (e.g. my topic) stays allowed.

• Broker admin creation paths now reject with HTTP 412 (PreconditionFailedException) instead of persisting an unreachable topic:

• Centralized create-time validation in AdminResource.validateCreateTopic(TopicName) (moved from PersistentTopicsBase) so persistent, non-persistent and scalable topics share one source of truth.

• BrokerService.isAllowAutoTopicCreationAsync returns false for such names, so auto-creation is also refused (covers clients that do not trim).

• Client admin fail-fast: TopicsImpl (partitioned + non-partitioned), NonPersistentTopicsImpl, and ScalableTopicsImpl now reject whitespace names locally and fail the future with PreconditionFailedException (412), consistent with the server response — so callers catching PreconditionFailedException work for both the client fast-fail and the server path.

Verifying this change

This change added tests and can be verified.

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

• The REST endpoints — topic create endpoints now return 412
  (PreconditionFailedException) for names with leading/trailing
  whitespace instead of persisting an unreachable topic.
• The public API — the admin client now rejects (412) topic names with
  leading/trailing whitespace that were previously accepted; this is a
  behavioral correction of a bug. Callers that never sent whitespace
  names are unaffected.
• Dependencies
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The admin CLI options
• The metrics
• Anything that affects deployment