Move CRD to apiextensions.k8s.io/v1 about snapscheduler

[JohnStrunk]

In both cases below, it is necessary to investigate installing updates (using v1) over top of v1beta1.

Helm

In the case of Helm, we currently deploy the CRD via its crds directory. Unfortunately, that mechanism doesn't have any pre-processing that would allow us to dynamically choose the proper apiextensions version.

Since we don't actually use the CR in the chart, it's not necessary for it to be deployed via the crds directory. Instead, it should be possible to move it into the templates directory and choose the correct version to deploy based on .Capabilities.KubeVersion.Version like we do here:

snapscheduler/helm/snapscheduler/templates/deployment.yaml

Line 58 in f230f7c

{{- if semverCompare ">=1.14" .Capabilities.KubeVersion.Version }}

OLM

I think this may come down to specifying a min kube version and stranding old clusters on old versions of the operator. This may be ok since OLM is primarily targeted at OpenShift and users would be expected to follow the upgrade cycle there.
The result would be that old clusters would stop getting operator updates (except for backported bugfix releases), but once the cluster is updated, operator updates would resume.

[JohnStrunk]

Removal of v1beta1 has been moved to kube v1.22:
kubernetes/kubernetes#82022 (comment)