[fix][test] Deflake TopicPoliciesTest.setupTestTopic by retrying forced namespace deletion - #25974

Motivation

TopicPoliciesTest.setupTestTopic (a @BeforeMethod) is flaky. It was observed failing in CI with:

org.apache.pulsar.client.admin.PulsarAdminException: HTTP 422 {}
    at org.apache.pulsar.client.admin.internal.NamespacesImpl.deleteNamespace(NamespacesImpl.java:207)
    at org.apache.pulsar.broker.admin.TopicPoliciesTest.setupTestTopic(TopicPoliciesTest.java:179)

The setup recreates the namespace before each test by force-deleting it. A forced namespace
deletion cascades through NamespacesBase#internalDeleteTopicsAsync, which deletes each topic via
the admin REST client. When a topic deletion races with concurrent topic loading, the broker raises
an IllegalStateException, which PersistentTopics#deleteTopic maps to HTTP 422 (with an empty
{} body when the exception message is null). The setup only caught NotFoundException (404), so
this transient 422 escaped and failed the test.

The failure is transient: in the same CI run 483/484 tests passed, i.e. the identical setup ran
successfully many times — only one invocation hit the race.

Modifications

Replace the two raw admin.namespaces().deleteNamespace(..., true) calls (each guarded only against
NotFoundException) with the existing MockedPulsarServiceBaseTest#deleteNamespaceWithRetry(ns, force)
helper, which already exists for exactly this purpose ("maybe fail by race-condition with create
topics, just retry"): it retries the forced deletion on transient errors and treats an
already-deleted namespace as success. No assertions were weakened; the test intent (reset namespace
state before each test) is preserved.

Verifying this change

• Make sure that the change passes the CI checks.

This change is already covered by existing tests, such as the whole TopicPoliciesTest suite. The
fix targets the @BeforeMethod that runs before every test in the class. Verified locally:
TopicPoliciesTest runs green (114 tests, 0 failures/0 errors), so setupTestTopic executed 114
times successfully. Note that this is a timing-dependent race, so a clean local run is only weak
evidence; the fix is structural — it reuses the codebase's established retry helper for this exact
race condition.

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