support dynamic config for authenticationEnabled

[lordcheng10]

Motivation

When we want to enable authentication on an already running cluster, the broker must be restarted in rotation. During the rotation restart, the connection between the authenticated broker and the temporarily unauthenticated broker may be abnormal.

We have a scenario where the client doesn't want to stop all.
So our upgrade process is:

The client restarts in turn to enable the authentication configuration;
After the client completes the upgrade, it will restart the broker in turn to enable the authentication of the broker, but at this time, in order to prevent the connection between the brokers from being abnormal during the rotational restart process, it is necessary to configure: authenticationEnabled=false
After the broker is upgraded, change the configuration through dynamic settings: authenticationEnabled=true

Documentation

Check the box below or label this PR directly.

Need to update docs?

• doc-required
  (Your PR needs to update docs and you will update later)

• no-need-doc
  (Please explain why)

• doc
  (Your PR contains doc changes)

• doc-added
  (Docs have been already added)

[liudezhi2098]

If authenticationEnabled in broker , the client also needs to enable the authentication configuration, which is currently not automatic, so dynamic config for authenticationEnabled may doesn't solve the problem.

[lordcheng10]

If authenticationEnabled in broker , the client also needs to enable the authentication configuration, which is currently not automatic, so dynamic config for authenticationEnabled may doesn't solve the problem.

We have a scenario where the client doesn't want to stop all. @liudezhi2098
So our upgrade process is:

1. The client restarts in turn to enable the authentication configuration;
2. After the client completes the upgrade, it will restart the broker in turn to enable the authentication of the broker, but at this time, in order to prevent the connection between the brokers from being abnormal during the rotational restart process, it is necessary to configure: authenticationEnabled=false
3. After the broker is upgraded, change the configuration through dynamic settings: authenticationEnabled=true

[lordcheng10]

/pulsarbot run-failure-checks

[lordcheng10]

/pulsarbot run-failure-checks

[lordcheng10]

/pulsarbot run-failure-checks

[Jason918]

So our upgrade process is:

1. The client restarts in turn to enable the authentication configuration;
2. After the client completes the upgrade, it will restart the broker in turn to enable the authentication of the broker, but at this time, in order to prevent the connection between the brokers from being abnormal during the rotational restart process, it is necessary to configure: authenticationEnabled=false
3. After the broker is upgraded, change the configuration through dynamic settings: authenticationEnabled=true

Make sense to me. You can put this in the motivation part.

[lordcheng10]

So our upgrade process is:

1. The client restarts in turn to enable the authentication configuration;
2. After the client completes the upgrade, it will restart the broker in turn to enable the authentication of the broker, but at this time, in order to prevent the connection between the brokers from being abnormal during the rotational restart process, it is necessary to configure: authenticationEnabled=false
3. After the broker is upgraded, change the configuration through dynamic settings: authenticationEnabled=true

Make sense to me. You can put this in the motivation part.

OK

[lordcheng10]

/pulsarbot run-failure-checks

[lordcheng10]

/pulsarbot run-failure-checks

[lordcheng10]

/pulsarbot run-failure-checks

[lordcheng10]

/pulsarbot run-failure-checks

[lordcheng10]

/pulsarbot run-failure-checks

[eolivelli]

This change seems risky and I am koto sure that the whole code base handles well this case (some classes may cache this value).

I believe that it deserves more discussion on the dev@ mailing list