Drop Kubernetes 1.22 variants

[stmcginnis]

Issue number:

Closes #2844

Description of changes:

This removes the 1.22 k8s variants. Kubernetes 1.22 went out of upstream support in April, 2022. AWS EKS is maintaining support for 1.22 until May 1st, 2023.

Note to reviewers

See #2700, #2421, and #2316 for examples of past removals of k8s version variants.

Testing done:

cargo make -e BUILDSYS_VARIANT=aws-k8s-1.23 -e BUILDSYS_ARCH=x86_64

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[jpmcb]

A few additional suggestions:

---

Update BUILDING.md

bottlerocket/BUILDING.md

Lines 150 to 157 in bf7dec9

	3. Build your image, setting the `BUILDSYS_UPSTREAM_SOURCE_FALLBACK` flag to `true`, if you haven't cached the driver's sources:
	```shell
	K8S_VERSION=1.22
	cargo make \
	-e BUILDSYS_VARIANT=aws-k8s-${K8S_VERSION}-nvidia \
	-e BUILDSYS_UPSTREAM_SOURCE_FALLBACK="true"
	```

---

There's a few spots in the README.md that call out 1.22 as a specific variant version:

bottlerocket/README.md

Lines 61 to 63 in bf7dec9

	The following variants support EKS, as described above:
	* `aws-k8s-1.22`

[stmcginnis]

As far as examples in the docs and code, we've taken the stance on some of them in the past not to update every time since they are only examples. As long as it doesn't apply to a specific instruction to the user, they shouldn't be included as an ongoing maintenance item.

But the list of variants was definitely a miss. Will update that now!

[jpmcb]

As far as examples in the docs and code, we've taken the stance on some of them in the past not to update every time since they are only examples.

If the variant is gone from the main branch, someone pulls the repository, and follows the instructions in BUILDING.md, doing cargo make -e BUILDSYS_VARIANT=aws-k8s-1.22 will fail.

We should update the docs to be as up to date as possible with the tip of develop - otherwise, it'll fall into disarray.

Edit: for example:

[cargo-make] INFO - Running Task: build-variant
ManifestParse: Failed to read manifest file '/home/ubuntu/workspace/bottlerocket-os/bottlerocket/variants/aws-k8s-1.22/Cargo.toml': No such file or directory (os error 2)
error: manifest path `variants/aws-k8s-1.22/Cargo.toml` does not exist
[cargo-make] ERROR - Error while executing command, exit code: 101
[cargo-make] WARN - Build Failed.

[stmcginnis]

As far as examples in the docs and code, we've taken the stance on some of them in the past not to update every time since they are only examples.

If the variant is gone from the main branch, someone pulls the repository, and follows the instructions in BUILDING.md, doing cargo make -e BUILDSYS_VARIANT=aws-k8s-1.22 will fail.

We should update the docs to be as up to date as possible with the tip of develop - otherwise, it'll fall into disarray.

I disagree for example snippets. If they ask to build a 1.22 variant and it doesn't exist, we would want that to fail. But I also don't think we want or expect someone building Bottlerocket to blindly copy and paste commands with no idea what they are asking for.

Let's see what other folks think. Happy to go with the consensus, but that's my 2 cents.

[etungsten]

I disagree for example snippets. If they ask to build a 1.22 variant and it doesn't exist, we would want that to fail. But I also don't think we want or expect someone building Bottlerocket to blindly copy and paste commands with no idea what they are asking for.

Ideally any code snippet we provide in the examples should not fail. Traditionally we'd update these every time we update the default variant to the latest aws-k8s-* variant but it seems like we've missed this one. It's weird that we have a divergence and we should probably fix it.

See https://github.com/bottlerocket-os/bottlerocket/pull/2593/files

[stmcginnis]

Traditionally we'd update these every time we update the default variant

OK, fair enough. I will update it to the current default to increase the chances it will be found the next time that is bumped.