[fix][broker] Fix a deadlock in SystemTopicBasedTopicPoliciesService during NamespaceEventsSystemTopicFactory init

[heesung-sn]

Motivation

Found a deadlock case in SystemTopicBasedTopicPoliciesService during NamespaceEventsSystemTopicFactory init

Deadlock case

"thread-1":
t1: prepareInitPoliciesCacheAsync(SystemTopicBasedTopicPoliciesService.java:338) (acquired the `policyCacheInitMap` lock)

t2: createSystemTopicFactoryIfNeeded(SystemTopicBasedTopicPoliciesService.java:599) (waiting for the `synchronized (this)` lock)


"thread-2":
t1: addOwnedNamespaceBundleAsync(SystemTopicBasedTopicPoliciesService.java:322) (acquired the `synchronized (this)` lock

t2: prepareInitPoliciesCacheAsync(SystemTopicBasedTopicPoliciesService.java:338) (waiting for the `policyCacheInitMap` lock)

Modifications

• Use a separate lock for the singleton NamespaceEventsSystemTopicFactory init by org.apache.commons.lang3.concurrent.LazyInitializer.

Verifying this change

• Make sure that the change passes the CI checks.

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

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository:

[mattisonchao]

LGTM. and it looks like the synchronized in addOwnedNamespaceBundleAsync method is useless now?

[heesung-sn]

it looks like the synchronized in addOwnedNamespaceBundleAsync method is useless now?

I think it is used to additionally synchronize the current access of addOwnedNamespaceBundleAsync.

[lhotari]

LGTM. Good work @heesung-sn !