Refactor to support resource version evolution

[stepanstipl]

As we want to provide most relevant advice to users, current implementation has its limitation as it's not able to support incremental recommendations, example being Ingress:

"Ingress": {
    "old": ["extensions/v1beta1", "networking.k8s.io/v1beta1"],
    "new": "networking.k8s.io/v1",
    "since": "1.14",
},

This does not allow to reflect the real situation where networking.k8s.io/v1 is only available since 1.19, and networking.k8s.io/v1beta1 since 1.14.

I.e. for someone running 1.18 we should ideally recommend upgrade to networking.k8s.io/v1beta1, but not v1, as that is not available yet. To allow this type of recommendations we need to capture version evolution properly, perhaps smth. like:

"Ingress": {
    "versions": [
        "extensions/v1beta1": { "since": "", deprecated: "1.16", removed: "1.22" },
        "networking.k8s.io/v1beta1": {"since": "1.19", deprecated: "1.16", removed: "1.22"},
        "networking.k8s.io/v1": {"since": "1.19", deprecated: "1.", "removed": "1.22"},
    ],
},

Maybe smth. like might be easier to work with:

"Ingress": {
    "versions": [
        [ "1.0": "extensions/v1beta1"],
        [ "1.14": "networking.k8s.io/v1beta1"],
        [ "1.19": "networking.k8s.io/v1"],
    ],
},

• We also need to support the case when a version is removed but does not have any replacement.

• Do we need info when version is removed? or deprecated really? We only care if it has replacement, and perhaps removal without replacement could be smth. like:

  [ "1.22": ""],
  

• Implementation-wise:

  • How easy is it to find if resource needs to be replaced?
  • And with what version?
  • Is this still a good use for rego? Or should we move this to Go...?

[stepanstipl]

Little POC to do this with rego - https://play.openpolicyagent.org/p/hVhVk5aimL

[jrhunger]

I think if done correctly this should also fix #455 ?
In that one the lack of awareness of older API versions keeps the namespace of resources from being captured/reported.