Implement TLS by default for operator Che installer

[mmorhun]

This issue is a part of TLS by default epic: #14742
We've implemented before TLS mode by default for Helm Che installer: che-incubator/chectl#476
Now we need to do the same for Operator Installer.

[mmorhun]

Some thoughts about this issue.

First, it is worth to mention that Che installation process on Openshift and Kubernetes are not the same thing. The most significant difference is Routes vs Ingresses.
So let's talk about each platform separately.

Openshift

By default, each Openshift cluster has its own certificate. As of now Che tries to reuse that certificate whatever it is. If it is commonly trusted - fine, everything works out of the box. But in case of self-signed certificate (which is the case for CRC, Minishift and many other Openshift instances) things get a little bit harder:

• First, user have to pass --self-signed-cert flag to chectl when deploying Che (or directly set it in Che CR). This requires understanding of what ssl certificate is and the term of self signed one. If user forgets to use this option Che will fail to start and the error is not obvious and it is not an easy task to detect it (probably we have to write some sort of test for it to understand, but need to investigate to say for sure). Also we may try to automate this process of detecting whether the certificate is self-signed or not, but again, this question should be investigated.
• Second, the CA certificate should be imported into users browser. We have detailed doc how to do it manually. But before importing we should have obtained the cluster certificate. And the process is far from being user friendly. Of course, it is not a problem for system administrator, but if a person wants to try Che on own dev cluster, well, let's say it is not comfortable to deal with. The good news is that it is definitely possible to retrieve the CA certificate from code, say chectl or other tool, so we may automate this process. As about automation of the certificate importing process into user's browser, I would like to not to do it as automatically, or at least it should be specified explicitly by user as it affects security stuff (and will probably require implementation for each OS and each browser).

Other than that, one may need to deploy Che with other than cluster certificate. As of now we do not have this ability, but it could be implemented as it is possible to configure some routes to use different from cluster wide certificates.

Kubernetes

By default Kubernetes doesn't have ingress controller installed and it is responsibility of cluster maintainer to do so. Which means there are a lot of possible configurations and it wouldn't be easy do deal with all of them and try not to break existing stuff.
Other problem is that there might not be a TLS at all, so we need to take care about using user-provided certificate or generate self-signed one.
Moreover, we need to deal with permissions. And depending on Che settings we need different level of cluster access...

In case of Minikube we may relatively easy automate the process as we did it for Helm Che installer. We know what's default ingress controller up to and we have cluster admin rights.

[mmorhun]

I think we should start with the most common problems / use-cases:

• automate TLS secrets creation in case of Kubernetes infrastructure: Implement automated generation of TLS secrets required for Che installation #16546
• retrieve CA certificate in case of Openshift infrastructure. This would be helpful to users to import the certificate into their browsers: chectl: add a command to export CA for already deployed Che #16278

[mmorhun]

The implementation of TLS by default is finished for most common use cases, no more manual certificates generation is required (but possible if one needs to).
In case of Kubernetes family infrastructures needed certificates and secrets will be generated and exported into file so users can easily add them into their systems/browsers.
In case of Openshift family infrastructures Che uses cluster certificate. To make flow comfortable, the certificate will be exported as in the Kubernetes case.
Also, a separate command chectl cacert:export is added to retrieve CA certificate if there is a need to add it for existing Che installation.
Docs haven't been updated yet, but this is out of scope of this issue and will be handled in terms of the epic issue or another subtask.