As an OpenShift developer, I want to ensure that WMCO can handle OpenShift/Kube major version upgrades even if a version of WMCO is not available in latest OperatorHub catalog for a OpenShift major release

Acceptance criteria:

• PR to allow a range of OpenShift releases in WMCO. For example we're at OpenShift release N, WMCO X should be able to run atleast on OpenShift N, N+1
• Atleast a manual test for now which tests upgrades are seamless across 4.6 to 4.7
• Update the version skew strategy in the WMCO enhancement

Engineering details:

Historically, there is a one-to-one mapping between WMCO's major release with OpenShift major release. For example, OpenShift 4.6's OLM catalog should have 1.x of WMCO and 4.7's OLM catalog should have 2.x of version. While this idea is not bad, considering the release process is manual there is a chance of missing out on a release. In those scenarios, WMCO might fail to come up on the latest version of OpenShift as the WMCO has a restriction within the code tying WMCO to a particular version of OpenShift release which blocks WMCO from running.

WMCO cannot handle major version upgrades as we are tied to a particular OpenShift version in WMCO code. WMCO is deployed via OLM and historically we wanted to move away from having this restriction in the WMCO code as we were thinking OLM should have a minimum kube version and max kube version in CSV. Unfortunately, OLM doesn't have a max version field and we need to follow up with OLM team to see if they're ok with having a field like that. Considering the current state of things, we can relax the kube version strict dependecy