[improvement][broker]Add replicate all subscription state switch on the broker side.

[yyj8]

Fixes #xyz
#23768

Main Issue: #xyz
#23768

PIP: #xyz

Motivation

In the current version of Pulsar, when performing cluster data synchronization, in order to continue consuming the consumption message location recorded in the source cluster after switching from the source cluster to the target cluster, it is necessary to configure the parameter repliceSubscriptionState=true on the client side to replicate the subscribed consumption location information.
There may be some issues with this, such as when my cluster needs to be migrated, if there are dozens of business teams involved in this cluster, then I need to align the migration action with all business teams to ensure that everyone switches and changes at the same pace.
However, this difficulty is very high, as there are complex upstream and downstream dependencies in the data flow between different businesses. At the same time, the business needs to modify the code online in order to replicate the subscription status, which makes our migration efficiency heavily dependent on the business.
For this scenario, we expect to have a global control switch for subscription state replication on the server, which can be enabled to replicate all subscription state information in the cluster without the need for business code modification.

Modifications

Add a switch on the broker side to replicate all subscription states from the source cluster to the target cluster.

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

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:
yyj8#11

[lhotari]

@yyj8 The feature added in this PR would need to be covered with a PIP. There's also #23770 which has been proposed just now. Could you work with together with @nodece so that we could combine both features in the same PIP since they are so closely related. That might also impact the design and implementation. /cc @nodece

[nodece]

@lhotari Good idea, I suggest we should add this feature to the #23770, I also required this feature.

[nodece]

This PR introduces an override for the replicateSubscriptionState configuration from the consumer level, which is currently correct for the version being worked on. However, this conflicts slightly with PIP #23770, which proposes a configuration at the namespace and topic levels to control subscription replication. The issue arises because PR #23770 assumes that the consumer-level configuration for replicateSubscriptionState is not set, and instead, replication behavior is driven by namespace and topic policies.

To avoid this conflict and align with PIP #23770, I propose modifying this PR to ignore the replicateSubscriptionState configuration from the consumer level. This would ensure that subscription replication is controlled exclusively by the namespace and topic policies.

If you can set the subscription replication in the namespace or topic level, I belive this should be correct.