[fix][broker] Fix Replicated Topic unload bug when ExtensibleLoadManager is enabled

[heesung-sn]

Motivation

Noticed that Replicated Topic is not unloaded upon setNamespaceReplicationClusters when ExtensibleLoadManager is enabled.

Modifications

• Fix unloading bundles upon namespace policy update. (isNamespaceBundleOwned didn't check the bundle ownership properly when ExtensibleLoadManager is enabled.)
• Do not replicate ExtensibleLoadManager internal topics (bundle state, broker and bundle load data topics) because they are only used for the local cluster.
• Copy ReplicatorGlobalNSTest for ExtensibleLoadManager.

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:

[github-actions]

@heesung-sn Please add the following content to your PR description and select a checkbox:

- [ ] `doc` <!-- Your PR contains doc changes -->
- [ ] `doc-required` <!-- Your PR changes impact docs and you will update later -->
- [ ] `doc-not-needed` <!-- Your PR changes do not impact docs -->
- [ ] `doc-complete` <!-- Docs have been already added -->

[Demogorgon314]

Can we also check the other place such as producer.close(), looks like it may also get stuck forever.

[heesung-sn]

Can we also check the other place such as producer.close(), looks like it may also get stuck forever.

I understand the producer.flush might get stuck if no leader broker is found in the cluster, but actually, I wonder how producer.close() can get stuck.

[Demogorgon314]

I understand the producer.flush might get stuck if no leader broker is found in the cluster, but actually, I wonder how producer.close() can get stuck.

Oh, I see it has operationTimeoutMs set to 30000, so it won't be stuck.

[lhotari]

@heesung-sn I think that this is triggering a problem in tests.

[heesung-sn]

Sure. We can comment out this line if this is problematic.