Background: Currently we have passthrough routes defined by default.
This has the drawback that the default cluster wild card cert of the cluster can't be used...

The main issue is that the quay root ca is a self-signed one and is untrusted by default!
With reencrypted routes the internal self-signed quay root ca isn't used for the outside world because the wild card cert of the cluster can be used easily...

Create rencrypted routes by default instead of the passhrough routes so the cluster admin has to provide. manage and maintain only one wild card cert for the cluster.

Story: As a Quay administrator using the Operator I want to rely on Operator-based TLS management for Quay-internal TLS to encrypted but also rely on OCP-based certificate provisioning and rotation using classic Routes so that I don't have to provide any certificates by default and still have all traffic encrypted.

Acceptance criteria:

• provide a managed component for controlling self-signed TLS cert generation and rotation by the Operator for Quay and the Quay Config Editor (unrelated to other components like Clair, Postgres or Redis)
• by default the TLS component is managed but opting out of TLS management should not require to opt out of managing Route
• when TLS is managed and route is managed the Operator should create an OpenShift Route using re-encrypt policy for Quay and the Config Editor, in this scenario the Operator has to enforce the EXTERNAL_TLS_TERMINATION setting as false
• when TLS is managed and route is unmanaged, the Operator should not create any Route but enforce EXTERNAL_TLS_TERMINATION to true, so that customers only direct TLS encrypted traffic at Quay
• when TLS is unmanaged and route is unmanaged, the Operator should not create any Route nor any certificates and ignore the EXTERNAL_TLS_TERMINATION setting, so that customers have full control over a custom certificate and ingress setup

Proposed component Configuration Matrix: