Run e2e,integration tests against kubernetes versions and ssl stacks

[clux]

As part of Kubernetes version policies for #684.
Actual proposed policies are in kube-rs/website#19 and is mostly in line with our current advice.

This is larger overhaul for the CI situation for e2e tests to at least guarantee that the various Kubernetes versions work:

Main stuff done:

• factored out integration tests from coverage job
• running integration tests against [mk8sv, latest] (found one timing issue)
• extend e2e incluster tests to run both ssl stacks
• add e2e compile test to verify mk8sv and latest feature sets
• extend integration tests to run against different cluster versions (but same feature set)
• update automation to bump mk8sv and badge (just bump-k8s also bumps minimum now)
• improve minimum verification from badges (both on MSRV and MK8SV)
• general ci workflow improvement on naming and organisation (lint factored into its own, lowercase names)
• update required statuses after review

k3s complication: k3s is lagging behind k8s; pre-releases available 1w later, but 1mo later no stable 1.24.. => pinning only minimum supported and running against latest => can only really test against minimum and max available.

Verification strategy:

• run integration tests against v1_19 (but without changing cluster version)
• compile e2e/boot.rs against both latest k8s-openapi feature and our msrv (currently v1_19 feature)

Thus the compile check avoids the error where we accidentally publish abstractions on apis that k8s-openapi have removed, and the integration tests run with a later k8s-openapi no matter what (because it's super hard to untangle that, and also not super necessary).

[clux]

Am fairly happy with the way this is now. It matches the policy in the upstream website PR, and we have better e2e tests to at least compile time guarantee we are not building on top of removed apis. Minor improvements here and there as outlined in edited main post. Feedback welcome.

EDIT: i guess the flaky test is still flaky. Will look at that later, but ultimately it should be unrelated to the rest of this PR.
EDIT2: Looks like the flaky test is due to discovery::oneshot::pinned_group in derived_resources_discoverable. It's possibly that this is a race condition within kubernetes apiserver. I.e. maybe waiting for established is not sufficient to try to discover the type. EDIT3: lol, yes looks like it.

[kazk]

Not sure why this is stuck.

By the way, I just enabled https://github.blog/changelog/2022-06-08-admins-can-require-sign-off-on-web-based-commits at org level, which will prevent the DCO issue when committing suggested changes.

[clux]

Not sure why this is stuck.

It's not actually stuck. This PR has changed jobs + job names, so I need to change required statuses before merging (hence why the required ones are not reported).

By the way, I just enabled https://github.blog/changelog/2022-06-08-admins-can-require-sign-off-on-web-based-commits at org level, which will prevent the DCO issue when committing suggested changes.

Ah, that sounds great. Thanks!