Allow use of a TLS secret with a cert signed by an external CA for the concierge impersonation proxy server cert

[nickperry]

Is your feature request related to a problem? Please describe.

Currently, if a cluster gets rebuilt or pinniped concierge namespace removed, once concierge is redeployed we have to retrieve the new pinniped-concierge-impersonation-proxy-ca-certificate and update the CA data in the kubeconfig we store in git and on our SSH jump hosts. Until this happens we have disruption to our enigneers' ability to work.

We want instead to be able to configure pinniped to use an alternative secret to pinniped-concierge-impersonation-proxy-tls-serving-certificate for serving the impersonation proxy. We can configure certmanager to provide this secret, using our external CA. Because the external CA is stable, our skeleton pinniped kubeconfigs which we distribute to users can also remain stable. This will reduce disruption to our engineers and increase user satisfaction.

Describe the solution you'd like

I am happy for pinniped to use its own CA for everything else, but for serving the impersonation proxy, I want pinniped to have the option to use a custom TLS secret with a key and external CA signed cert.

Describe alternatives you've considered

Some sort of CI job to retrieve the new pinniped-concierge-impersonation-proxy-ca-certificate from a cluster and update it automatically in git. This is clunky though and we then still need to get it from git to our engineer userbase.

[voor]

This issue might be related to #1104

Would that capability also solve this problem?