The `ClusterOperatorConfig` class has become quite messy over time. It has a static method which parses the configuration input (Map with environment variables) to create a local variables. And then passes them to a constructor which covers all of these values. Later, getters are used to get the different configuration values from the config object.

Getting the values from the config through getters seems to work relatively well and should be probably kept. But the way how this is constructed is quite messy:

A very large constructor with over 20 different fields
Adding new values is messy
In tests, it is fairly common that you want to change one particular value for a given test. But the config class is final and the constructor with 20 fields is a mess because you cannot configure just a single value. You have to configure all of them.
We should try to improve how the config instances are created and how can they be flexibly modified. For example using some builder pattern or something similar. Maybe we can look for inspiration somewhere? The Topic Operator is using different logic => does that work any better? The Fabric8 Kubernetes client uses a builder pattern. Does that work well?

Created by Strimzi#7593