Improve cluster type (Kubernetes or OpenShift) detection on operator startup

[amisevsk]

Description

DWO needs to configure its behaviour based on whether it is running in OpenShift or Kubernetes (for example, setting default pod security context, using routes instead of ingresses). This is normally done by checking if OpenShift-specific APIs are being served by the cluster (routes, projects, templates, etc.). However, when a cluster enters a degraded state it can result in API errors that prevent access to any objects on the cluster. This causes the operator to

• Fail at leader election, resulting in the controller pod restarting
• Fail to check for OpenShift APIs on the cluster

If the cluster then recovers from the degraded state, DWO will be left running under the assumption that it is in a Kubernetes cluster. This can result in workspaces failing to start due to an invalid pod security context (i.e. user ID is 1234 instead of unspecified).

How To Reproduce

Not consistently reproducible, unclear what causes cluster degraded state.

Expected behavior

DWO should improve how it detects cluster type in some way to avoid this issue.

Additional context

This issue manifests due to changes in #953 -- previously, configured pod security contexts were ignored on OpenShift and so the default value did not matter.

[amisevsk]

After various attempts to reproduce the degraded cluster state that triggers this issue and failing, I've decided to close this issue as unreproducible.

If anyone encounters this again, we can reopen.