Different TLS certificates for internal and external communication

Story: As a Quay administrator I would like to use signing services like Let's Encrypt or an enterprise PKI so that registry clients trust the TLS certificates served by Quay. These should be different from the certificates that Quay uses for it's internal communication.

Why is this important: Today the Operator requires that customer provided certificates use certain Subject Alternate Names which can only be resolved from inside the Kubernetes cluster. This makes it impossible to use PKI and signing providers external to the cluster, like Let's Encrypt. Using PKI is very common in enterprise environments. The limitation prevents enterprise users from supplying company-managed certificates to Quay.

Acceptance criteria:

• Quay Operator allows to provision separate certificates for internal and external communication
• Quay relies on Server Name Indication to return the external certificate instead of the internal one to registry clients
• * Quay relies on Server Name Indication to return the internal certificate to the client instead of the external one to other Quay deployment components like Clair