CABundle Implementation as a part of Certificate Management

The current interface struct accepts CABundle as a `[]byte` slice: https://github.com/etcd-io/etcd-operator/blob/e94c901772e5d69aedf816b8594871e09a14709e/pkg/certificate/interfaces/interface.go#L18-L23

When wrapping the CertManager config: https://github.com/etcd-io/etcd-operator/blob/02f3287262a0f32e4f398dabd8ea06967c3ef77b/api/v1alpha1/etcdcluster_types.go#L58-L62 as the generic config I have found a few challenges on how the user-input to the etcd-operator CR yaml should be.

I was exploring the following user-input scenarios for the CABundle field:

- CABundle as a byte array of base64 encoded PEM string
- CABundle as a secret name string

Challenges:

- The CABundle will be exposed as a part of the etcd-operator CR and anyone can decode it since its base64 encoded
- When creating the CABundle secret, the controller has to check if the data in the CABundle string from etcd-operator CR and the existing CABundle secret is same or not.
- If the data is not same, the secret needs to be deleted and recreated. In doing so, there can be multiple scenarios where the deletion or recreation fails or there is a race-condition.

If we accept CABundle as a secretName from the user, assuming the user would have already created the CABundle secret, we will not run into the above problems. Also, if the CABundle needs to be changed, a new CABundle secret can be created async by the user(by creating the secret) and updated later in the etcd-operator certificate config when there is no workload running without overwriting the existing CABundle secret.

CertManager Provider implementation flow(ref: https://cert-manager.io/v1.6-docs/configuration/ca/#deployment):

- The CABundle is expected to be stored as a secret
- An Issuer is then created using this secret
- This Issuer is then used to issue certificates

cc @ahrtr @hakman @ivanvc @jberkus @justinsb