Change the data model for Acceptable Bundles

[lcarva]

The acceptable bundles data is modeled as such:

<type>-bundles:
  <repo>:
    - digest: <digest>
      effective_on: <timestamp>
      tag: <tag

For example:

task-bundles:
  quay.io/redhat-appstudio-tekton-catalog/task-buildah:
    - digest: sha256:c37e542031de193398cd54463af146e42539b5f5c9082df56d65354494566db0
      effective_on: "2023-11-06T00:00:00Z"
      tag: "0.1"
    - digest: sha256:97f21661e237735af04b37feeeaedd328424bfa0ebd4cd0f79ac39cde17137f6
      effective_on: "2023-10-25T00:00:00Z"
      tag: "0.2"

Then there's rego that interprets this data to do the right thing.

Sometimes we use the value of tag to determine what is the latest version for that particular tag. In such cases, there are really virtual lists, one for each tag value.

The reality is that there is always a tag value, and we could make that a requirement. This issue is about changing how the data is represented, for example:

task-bundles:
  quay.io/redhat-appstudio-tekton-catalog/task-buildah:
    "0.1":
      - digest: sha256:c37e542031de193398cd54463af146e42539b5f5c9082df56d65354494566db0
        effective_on: "2023-11-06T00:00:00Z"
    "0.2":
      - digest: sha256:97f21661e237735af04b37feeeaedd328424bfa0ebd4cd0f79ac39cde17137f6
        effective_on: "2023-10-25T00:00:00Z"

This would impact ec track bundle (may need to add code to convert things on the fly to allow for an easier transition), and ec-policies (may need to support both formats for a bit).

[simonbaird]

Another possible way to do it:

task-bundles:
  quay.io/redhat-appstudio-tekton-catalog/task-buildah:0.1:
    - digest: sha256:c37e542031de193398cd54463af146e42539b5f5c9082df56d65354494566db0
      effective_on: "2023-11-06T00:00:00Z"
  quay.io/redhat-appstudio-tekton-catalog/task-buildah:0.2:  
    - digest: sha256:97f21661e237735af04b37feeeaedd328424bfa0ebd4cd0f79ac39cde17137f6
      effective_on: "2023-10-25T00:00:00Z"

[lcarva]

I like @simonbaird suggestion for various reasons:

1. It doesn't require a data schema change.
2. <repo>:<tag> feels like a natural way to express container image references.
3. Has the potential of making migration easier, e.g. ec-policies could look for <repo>:<tag> and fallback to <repo>.