c8d: Multi-platform image list

[vvoland]

• needs: c8d/list: Add test and combine size #47449
• related to: UX: improve / design UX for multi-arch images #44582 (comment)

Add the PlatformImages field to ImageSummary.
The original proposal was to enhance ImageSummary with Platform ocispec.Platform and Images []ImageSummary fields, but IMO having a separate type gives us more flexibility.

CLI initial implementation: docker/cli#4982

- How to verify it

$ docker pull busybox
$ docker images --tree

- Description for the changelog

- containerd image store: `GET /images/json` response now includes `PlatformImages` field, which contains information about the platform-specific manifests available for the image.
> [!WARNING]  
>
> This is experimental and may change at any time without any backward compatibility.

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

[vvoland]

Hmm CI fails with:

diff --git a/api/types/image/summary.go b/api/types/image/summary.go
index 4ebbdeadf7..fed2746521 100644
--- a/api/types/image/summary.go
+++ b/api/types/image/summary.go
@@ -54,7 +54,7 @@ type Summary struct {
 	// WARNING: This is experimental and may change at any time without any backward
 	// compatibility.
 	//
-	PlatformImages []PlatformImage `json:"PlatformImages,omitempty"`
+	PlatformImages []PlatformImage `json:"PlatformImages"`
 
 	// List of content-addressable digests of locally available image manifests
 	// that the image is referenced from. Multiple manifests can refer to the

Please update api/swagger.yaml with any API changes, then 
run hack/generate-swagger-api.sh.

Even though I marked this one with x-omitempty 🤔

[vvoland]

Looks like it's an issue with the outdated go-swagger, see #47827 for update

[vvoland]

Disabled swagger model generation for this struct: 5eb892a

[vvoland]

moby/api/types/image/summary.go

Lines 50 to 58 in 5eb892a

	// Platform-specific images available for this image.
	//
	// Only present with the containerd integration enabled.
	//
	// WARNING: This is experimental and may change at any time without any backward
	// compatibility.
	//
	PlatformImages []PlatformImage `json:"PlatformImages,omitempty"`

Thinking about it a bit more, I think we might want to expose all manifests details, not only the platform-specific images, so we can also provide information about build attestations (and possibly other things in future).

	// Manifests is a list of image manifests available in this image.  It
	// provides a more detailed view of the platform-specific image manifests or
	// other image-attached data like build attestations.
	//
	// WARNING: This is experimental and may change at any time without any backward
	// compatibility.
	//
	Manifests []ImageManifestSummary `json:"Manifests,omitempty"`

type ImageManifestKind string

const (
	ImageManifestKindImage       ImageManifestKind = "image"
	ImageManifestKindAttestation ImageManifestKind = "attestation"
	ImageManifestKindUnknown     ImageManifestKind = "unknown"
)

type ImageManifestSummary struct {
	ID string `json:"Id"`
	Descriptor ocispec.Descriptor `json:"Descriptor"`
	Available bool `json:"Available"`
	ContentSize int64 `json:"ContentSize"`

	Kind ImageManifestKind `json:"Kind"`
	// Fields below are specific to the kind of the image manifest.

	// Present only if Kind == ImageManifestKindImage.
	ImageData ImageProperties `json:"ImageData,omitempty"`

	// Present only if Kind == ImageManifestKindAttestation.
	AttestationData AttestationProperties `json:"AttestationData,omitempty"`
}

type ImageProperties struct {
	Platform ocispec.Platform `json:"Platform"`
	UnpackedSize int64 `json:"UnpackedSize"`
	Containers int64 `json:"Containers"`
}

type AttestationProperties struct {
	// For - the digest of the image manifest that this attestation is for.
	For digest.Digest `json:"For"`
}

This would also leave the gate open for adding any other manifests types in future.

WDYT?