…pache#7305)

A partition log in initialized in following steps:

1. Fetch log config from ZK
2. Call LogManager.getOrCreateLog which creates the Log object, then
3. Registers the Log object

Step linkedin#3 enables Configuration update thread to deliver configuration
updates to the log. But if any update arrives between step linkedin#1 and linkedin#3
then that update is missed. It breaks following use case:

1. Create a topic with default configuration, and immediately after that
2. Update the configuration of topic

There is a race condition here and in random cases update made in
second step will get dropped.

This change fixes it by tracking updates arriving between step linkedin#1 and linkedin#3
Once a Partition is done initializing log, it checks if it has missed any
update. If yes, then the configuration is read from ZK again.

Added unit tests to make sure a dirty configuration is refreshed. Tested
on local cluster to make sure that topic configuration and updates are
handled correctly.

Reviewers: Jason Gustafson <jason@confluent.io>

…pache#7305)

A partition log in initialized in following steps:

1. Fetch log config from ZK
2. Call LogManager.getOrCreateLog which creates the Log object, then
3. Registers the Log object

Step linkedin#3 enables Configuration update thread to deliver configuration
updates to the log. But if any update arrives between step linkedin#1 and linkedin#3
then that update is missed. It breaks following use case:

1. Create a topic with default configuration, and immediately after that
2. Update the configuration of topic

There is a race condition here and in random cases update made in
second step will get dropped.

This change fixes it by tracking updates arriving between step linkedin#1 and linkedin#3
Once a Partition is done initializing log, it checks if it has missed any
update. If yes, then the configuration is read from ZK again.

Added unit tests to make sure a dirty configuration is refreshed. Tested
on local cluster to make sure that topic configuration and updates are
handled correctly.

Reviewers: Jason Gustafson <jason@confluent.io>

…e (audit P0 #3)

The 'maintenance.broker.list' dynamic config still parsed but had no
runtime effect: KafkaConfig.getMaintenanceBrokerList was 'Seq.empty // LI
stub', so the controller no longer factored maintenance brokers into its
decisions, and the MaintenanceBrokerCount gauge was missing.

Restoration scope (this commit):
- DynamicConfig.Broker: register MaintenanceBrokerListProp via
  brokerConfigDef.define(...), restore DefaultMaintenanceBrokerList,
  MaintenanceBrokerListDoc, ClusterLevelConfigs, the
  getMaintenanceBrokerListFromString helper, and
  MaintenanceBrokerListValidator.
- DynamicBrokerConfig: restore getMaintenanceBrokerList that reads
  the prop from dynamicDefaultConfigs.
- KafkaConfig.getMaintenanceBrokerList: replace stub with delegation
  to dynamicConfig.
- KafkaController: restore MaintenanceBrokerCount gauge so LI ops
  dashboards see active-controller maintenance broker count.

ControllerContext.partitionUnassignableBrokerIds(Seq[Int]) is already
present in 3.6-li, so the helper is intact.

Out-of-scope follow-up: the rearrangePartitionReplicaAssignmentForNewTopics
LI method (which used to consume getMaintenanceBrokerList at the topic
auto-creation path) was removed entirely from 3.6-li KafkaController.
Restoring that requires re-integrating the LI logic into the new 3.6
auto-create flow and is filed as a separate audit P2 item.