Always propogate router certificate into trust store

[mmorhun]

Signed-off-by: Mykola Morhun mmorhun@redhat.com

What this PR does

Deprecates selfSignedCert option. CR value is present but actually has no effect.
In case of Openshift router certificate will always be propagated to Che trust store.
In case of Kubernetes certificate is generated and propagated into Che trust store unless use provides single TLS secret (no self signed one): then we consider certificate commonly trusted.

Related issues:

eclipse-che/che#16764

Tests

Tested on the following infrastructures with self-signed certificates:

• Minikube
• CRC
• Openshift (with oAuth)

[davidfestal]

OK with that if it has been deeply tested with running workspaces in various combinations:

• TLS on a cluster with self-signed routes
• TLS on a cluster with a valid certificate in the router.

I somehow remember that, long ago, enabling selfsignedcerts (=> adding the self-signed certificate chain extract from a dummy route) when it was not necessary (valid cluster router CA) was leading to problems as well.

[AndrienkoAleksandr]

I think these unused dependencies spawns older go. We have similar discussion eclipse-che/che-machine-exec#83 (comment) I think you should use a bit newer go to avoid this.

[AndrienkoAleksandr]

With newer go: go mod tidy and you will see that newer go will remove these deps from go go.mod

[mmorhun]

This changes is come when I build operator image in docker.

[AndrienkoAleksandr]

Looks good. Only one minor comment.

[mmorhun]

@davidfestal do you remember what kind of problems causes an attempt to add commonly trusted certificate into trust store?

[centos-ci]

Operator updates test passed

[mmorhun]

Rebased

[mmorhun]

Rebased

[centos-ci]

Operator updates test passed

[centos-ci]

Operator updates test passed

[mmorhun]

Closing this in favour of #301 because propagation of router certificate all the time leads to malfunction of some components in case of commonly trusted certificate.