WHAT

Fleetshard needs to expose a mechanism to enable/disable topic config policies until we are ready to enable the feature permanently.

WHY

Feature gating / leaving the feature turned of until the end to end tests are written.

HOW

One way could be to add another property like maximumSessionLifetimeDefault on org.bf2.operator.operands.KafkaInstanceConfiguration.Kafka which will be used to control setting of kas.policy.topic-config.topic-config-policy-enforced in the configuration passed to the broker.

However, I wonder whether we should build a generic override mechanism into fleetshard that allows us to pass arbitrary additional config values through to the broker.  This would have utility in this use-case and others in the future.   My idea is to use approach from https://github.com/bf2fc6cc711aee1a0c2a/kas-fleetshard/pull/742 . We'd specialised Kafka's OperandOverride to provide an kafkaConfig Map<String,Object>.  We'd have org.bf2.operator.operands.KafkaCluster#buildKafkaConfig pull in any kafka config defined in the the operand override.  That would give us a simple mechanism to pass kafka config straight from the strimzi-cluster-operator.v0.xx.x-yy configmap.

DONE

Include the following where applicable:

• Mechanism to override enable/disable topic config policies built and tested.