Define supportability for k8s versions about osm-docs

[shashankram]

This issue pertains to defining the following:

• Min and max k8s versions to support
• Duration of support for a particular version
• Deprecation policy

For the above 3:
We support the k8s version skew, which means we no longer support k8s versions that are deprecated upstream. This is indicated by the kubeVersion field in the Helm chart. We should support the latest released version, which the CI automatically picks up.

• Breaking change policy
  We need to define and enforce this once v1.0 is cut. We should try to at least support N-1 versions, which means we should not be deprecating fields in the Helm charts without giving users enough notice.

For CRDs, deprecating fields are allowed as long as there is a conversion webhook in place to convert from the old version to the new version. Otherwise, the N-1 rule must be followed.

[trstringer]

Some applicable information for this topic:

Here is a good description on Kubernetes version skew. Here are the current Kubernetes releases. Note that 1.19 is about to End of Life on October 28th. So currently OSM support is >= 1.19 and <= 1.22. When there is a Kubernetes release we should add a reminder (shared calendar?) for the new release's end of life date. On that day, we should remove this version from kubeVersion in the Helm chart.

The kubeVersion in the Helm chart is where we specify the supported Kubernetes version. On October 28th, this should be bumped to 1.20.0-0.

[draychev]

Note: at each release we look at EOL'ed Kubernetes versions and document/state that we support only these. For example 1.19 will be EOL'ed on 2021-10-28. OSM releases cut after 2021-10-28 (ex v0.12)will no longer support Kubernetes 1.19. If we release v0.11.2 (current +1 minor) - we need to continue to support K8s v1.19 (which was supported by previous OSM release -v0.11.1)