Extend secret reading for webhook certificates

[skonto]

Webhook Certificates reconciler's logic will update secrets contents if the secret is expired or if the secret is empty.
We start with an empty secret so the reconciler can generate its contents. This is an internal process. There is a hardcoded value for renewal (1 day).

However there are two candidate use cases we may want to consider extending this logic for:

a) users operate their infra with specific certificates for all their stuff. Examples:

• certificate manager integration
• vendor specific capabilities eg. OCP service ca certificates
• manual/custom secret management/renewal
• other solution

b) developers may want to use this repo for generic webhook development

This relates to: #1972 but that ticket is focused beyond secrets and here the goal is to add support for using a secret that already contains a certificate and it is externally managed. There are some options wrt to what flexibility to provide (assuming the reconciler is not removed from the picture):

a) Some validation could happen at the reconciler side as it is now eg. expiration logic to warn users.
b) User provides a CA bundle and the reconciler creates the rest of the keys.
c) User provides all certificates CA/TLS keys and so the reconciler can be used for validation.

Older slack discussion on this topic here.

/kind feature

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[skonto]

/reopen

[knative-prow]

@skonto: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.