SecretClasses used to validate Server certificates require client certificate as well

[sbernauer]

There are multiple places where our products are TLS clients, e.g. S3 or LDAP. Currently we offer the possibility to mention a SecretClass, which provides the ca.crt.
Previously we mounted the SecretClass and stuffed the ca.crt into the truststore and everything was fine.
With 23.11 we started using secret-ops functionality to create the truststore for us.
However, secret-op creates a trust and keystore at the same time, bailing out if tls.crt or tls.key is missing.
Besides only the ca.crt should be needed, users need to provide some bogus tls.crt and tls.key to make secret-op happy.

The plan is to have a new annotation (such as secrets.stackable.tech/provision-identity as a boolean or e.g. some other attribute with e.g. values public / private), which controls if you only get the public parts (ca.crt for tls-pem, trsustore for tls-pkcs12 and krb5.conf for kerberos) or all parts (as currently done).
For compatibility reasons we should probably default to only the private parts. In operator-rs the SecretOperatorVolumeBuilder needs to expose this new attribute, it IMHo should be made mandatory, so every product operators needs to make a call what exactly he needs.

Related to stackabletech/secret-operator#320