feat: add metric about tls cert expiration in secrets

[sylr]

What this PR does / why we need it:

Add a kube_secret_tls_cert_not_after_seconds to get certificate expiration dates.

How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality)

Increase cardinality.

[k8s-ci-robot]

This issue is currently awaiting triage.

If kube-state-metrics contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

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-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sylr
Once this PR has been reviewed and has the lgtm label, please assign dgrisonnet for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Serializator]

The below is my opinion and a description of my concerns from a non-maintainer's perspective. There is no ill-intent and I respect the time and effort it takes to contribute. Please read this with a few 😄 in between!

---

KSM may not be the right place to monitor details of a TLS certificate. I'd argue the data inside of a secret is not directly pertinent to the state of a Kubernetes cluster itself.

The inability to report problems with decoding the certificate may also add ambiguity when troubleshooting problems where the metric does not appear for a given secret containing a TLS certificate.

Kubernetes offers sugarcoating by means of the TLS secret type to more easily manage TLS certificates as secrets. However, the Kubernetes API itself does not directly interpret or subsequently expose any details about the TLS certificate.

The TLS Secret type is provided only for convenience. You can create an Opaque type for credentials used for TLS authentication. However, using the defined and public Secret type (kubernetes.io/tls) helps ensure the consistency of Secret format in your project. The API server verifies if the required keys are set for a Secret of this type.

Source - https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets

Decoding of (semi-)unknown data should not be KSM's responsibility.