Create ADR for exposing TLS endpoints and required SecretClass/AuthenticationClass via discovery ConfigMaps

We enable more and more operators to use TLS for their products. We have dependencies between operators via discovery (e.g. Kafka -> ZooKeeper) where we currently expose a connection string (adapted to the secure port etc.), but we do not expose what secret class or authentication class must be used if authentication is required. After, a quick discussion with Sönke we agreed that we need to expose the secret or authentication class (e.g. the one used for client TLS in ZooKeeper) in the discovery ConfigMap.

For ZooKeeper we currently expose 3 fields:

• ZOOKEEPER contains the full zookeeper connection string with znode (generally used)
• ZOOKEEPER_CHROOT contains the znode (i think only for Nifi currently)
• ZOOKEEPER_HOSTS contains the zookeeper connection string without znode (i think only for Nifi currently)

I think we should (if set) in similar fashion secure fields like:

• ZOOKEEPER_SECURE
• ZOOKEEPER_HOSTS_SECURE
• (ZOOKEEPER_CHROOT_SECURE) would be redundant
• AUTHENTICATION_CLASS

to be able to connect products to e.g. ZooKeeper.

This should be properly discussed and documented in an new ADR, provided in machine readable format (yaml, json) and valid for different products.

No files or tests are named. Start by reviewing the existing discovery ConfigMaps and the three ZooKeeper fields listed in the issue, then define the product-independent conventions the ADR must cover. Done means a discussed, documented ADR in valid YAML or JSON describing secure endpoints and required SecretClass or AuthenticationClass fields.