Add test for k8s version recency (#288)

[cah-hbaum]

This PR adds a test for the K8s version recency standard.
A user can execute the test script and provide his Kubernetes Cluster config file in order to check if the cluster version
is still in line with the versions demanded by the standard.

The following requirements are set:

• Minor version is not older then 4 months
• Patch version is not older then 1 week
• Versions with CVEs need to be patched faster

This PR also adds a configuration file for the test script, which allows setting different logging parameters as well as the Github Token required to access the latest K8s release information in a readable format.

Closes #288

[cah-hbaum]

The things we also might want to think about here:

• a Github Token needs to be used in order to access the API calls to Github
• the recency variables could also be set/changed in the config, if we want to be flexible with respect for the standard
• Versions with CVEs need to be patched faster this section should probably defined better

Some improvements I also thought about:

• this test could be sped up by either
  a) caching the CVE data for repeated uses somehow, since they take the most time or
  b) adding a --disable-cve option, which would disable it for the requested runs (but this would go against the Standard)
• test multiple clusters by providing multiple files (or just call the test multiple times, but this would require the caching solution from before)

[cah-hbaum]

Please add more/other reviewers if required!

[mbuechse]

I think this implementation does get the job done, and I also think that a lot of important research went into it (for finding the right endpoints for the Kubernetes releases and CVE data). Nevertheless, from my point of view, it needs a bit of polish here and there.

• the naming of the functions should better reflect what they do
• the functions also seem to mix levels of abstraction and concerns that I would prefer to see separated
• async should be capitalized on more
• some of the logic seems bit convoluted

[mbuechse]

One thing that I forgot: This PR should also replace the TBD in the standard by just one paragraph explaining the name of the script and how to invoke it properly (this wouldn't warrant a dedicated issue in my opinion).

[cah-hbaum]

As per suggestion of @jschoone, I looked into Trivy.
In general, it looks like a nice tool with many possibilities, which can provide an overview for all vulnerabilities.

The only two problems I see is that trivy doesn't provide an interface/API for other programs (at least I didn't find one during checking). Maybe their CI pipeline integration could be useful here, but that would need further investigation from my side.
If we then would need to use the output given by the trivy application, we would again need to parse this. But at least this would be standardized.

If someone else has opinions on this, I'm open for discussions/suggestions/etc.

[cah-hbaum]

I think, I fixed/changed most of the problems/things found, please provide more feedback if anymore problems arise. Thank you for your contribution.

[fdobrovolny]

Approved by mistake. Mostly LGTM.