containerd integration: handle multi-platform images

[laurazard]

Signed-off-by: Laura Brehm laurabrehm@hey.com

- What I did

Fix listing images with containerd store

Upstreams:

• Handle multi-platform images when listing them rumpl/moby#113
• c8d/list: Make dangling images parseable by the cli rumpl/moby#126

- How I did it

Multiple entries are returned for each platform of an image (more discussion here: rumpl#113) – which isn't fantastic, but is better than the current state where listing images is broken.

- How to verify it

• docker pull --platform=linux/amd64 alpine:latest
• docker images (verify it doesn't break)
• docker pull --platform=[another platform] alpine:latest
• docker images (verify another entry is returned)

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[tianon]

This is likely good (for now?), but we probably also want to come to a decision on #44582 before we get too deep. 😅

(I think this is on me and other maintainers -- we need to participate more over there and I'll go leave some of my thoughts we'd talked about in a previous maintainer meeting over there 🙈)

To be clear, I think something beats nothing here, and do not personally believe that should be a blocker for this PR (because I don't think any implementation here is going to make it harder one way or another to implement something else). 👍

[laurazard]

@tianon I agree! I made this because I was running into not being able to list my images while refactoring for the other PRs to solve the platform issues associated with #44958 and #44934.

This PR just makes things a little smoother for now, and we can come to a better solution from discussion in #44582.

[neersighted]

We discussed this extensively in the context of #44840 -- there were a couple takeaways:

These PRs both introduce isDanglingImage and <none>:<none> strings -- so we'd like to see the common parts factored out into a third PR that these two can then be re-stacked on.

In particular, centralizing the <none> string constants in the presentation layer and using a sentinel value (possibly the empty string) to represent untagged images in the plumbing layer makes a lot of sense. We should quarantine those values to the API, so that we can possibly deprecate them in favor of client-side presentation in a future API version.

Likewise, isDanglingImage should be factored into a common place for both these PRs (and then consumed by restacking on top of the common PR), as otherwise when both are merged the symbols will collide as they're in the same package.

[laurazard]

As discussed in #44840 (comment) (and since it's been merged in the meantime), I rebased this PR on top of master and addressed @neersighted's comments. PTAL :)

[neersighted]

LGTM!

[thaJeztah]

First PR in; congrats!