To branch or not to branch on k8s API versions

This is the question.

## Issue

The operator uses the k8s api and we have to follow the versioning practice that k8s maintains.

https://kubernetes.io/docs/concepts/overview/kubernetes-api/

So we cannot run an operator with k8s api 1.22 on an 1.20 k8s cluster.

## Open questions

So what do we need to support? How many versions of k8s does the operator need to support? At this point we are upgrading master with the API version.

## Solutions

Two ways to handle this in my mind. I would love more ideas

1. The latest operator does not support very old versions of k8s
2. We maintain branch releases and multiple versions of the operator. Much like k8s and crdb

We do need a documented support matrix.

I also do not know how supporting multiple different released versions works with open shift.