Create and push syndicated tags during builds

[lbussell]

Aspire Dashboard images will be syndicated for a period of time. When attempting to publish syndicated aspire dashboard images, the post-build stage failed with:

Failed to execute docker manifest create --amend
  msdotnetcontainersstaging.azurecr.io/build-staging/3076999/dotnet/nightly/aspire-dashboard:13.6.0 
  msdotnetcontainersstaging.azurecr.io/build-staging/3076999/dotnet/nightly/aspire-dashboard:13.6.0-amd64
  msdotnetcontainersstaging.azurecr.io/build-staging/3076999/dotnet/nightly/aspire-dashboard:13.6.0-arm64v8
    
  no such manifest: msdotnetcontainersstaging.azurecr.io/build-staging/3076999/dotnet/nightly/aspire-dashboard:13.6.0-amd64

In this instance, dotnet/nightly/aspire-dashboard is the syndicated version of the image.

The manifest list creation task attempts to create the syndicated manifest lists, but since the syndicated platform-specific tags haven't been created yet, it fails.

Historically, here is how syndication worked:

Prior to #2030 (aka the last time we had working syndication):

• Build stage:
  • builds images
  • tags built images with primary platform-specific tags
  • tags built images with primary multi-platform tags
• Post-build stage:
  • does nothing with tags or syndication
• Publish stage:
  • creates and publishes manifest lists
  • creates all syndicated tags and manifest lists

After #2030:

• Build stage:
  • builds images
  • tags built images with primary platform-specific tags
  • tags built images with primary multi-platform tags
• Post-build stage:
  • creates manifest lists
  • creates syndicated manifest lists (this is what is breaking today)
• Publish stage:
  • copies all tags (primary + syndicated) to publish destination

With the changes from this PR:

• Build stage:
  • builds images
  • tags built images with all platform-specific tags
  • tags built images with all multi-platform tags
• Post-build stage:
  • creates manifest lists
  • creates syndicated manifest lists (will now succeed)
• Publish stage:
  • copies all tags (primary + syndicated) to publish destination

---

You may be wondering, "Why not have the Build/Post-Build stages operate only on primary tags, and just create syndicated tags as part of publishing?"

This approach is appealing, but the current manifest/syndication model is on a tag-specific basis. This means that platforms may participate selectively in syndication.

If an image has platforms [A, B, C], but only platforms [A, B] are syndicated with shared syndicated tags, then that necessitates a new manifest list [A, B] be created. Thus, we must create it during Build/Post-Build and not during Publishing (so that it can get signed, etc.).

I would like to simplify the syndication model to image-level instead of tag-level, but I will leave that as follow-up work. This PR is required to unblock syndication of Aspire Dashboard images.

[mthalman]

What about signing? ImageSigningService calls GetAllDigests:

docker-tools/src/ImageBuilder/Signing/ImageSigningService.cs

Line 53 in 609846d

.GetAllDigests()

But that implementation does not handle syndication:

docker-tools/src/ImageBuilder/ImageInfoHelper.cs

Lines 70 to 82 in 8f2d2aa

	public static List<string> GetAllDigests(this ImageData imageData)
	{
	// Platform specific digests
	IEnumerable<string> digests = imageData.Platforms.Select(platform => platform.Digest);
	// Include manifest list digest if it exists
	if (imageData.Manifest is not null)
	{
	digests = [ ..digests, imageData.Manifest.Digest ];
	}
	return digests.ToList();
	}

That means that digests addressed by aspire/dashboard would be signed but not digests at dotnet/aspire-dashboard.

[lbussell]

@mthalman fixed in 45a5657 by:

• Making ImageInfoHelper.GetAllDigests includes SyndicatedDigests.
• Ensuring that SyndicatedDigests have proper registry overrides (to account for build staging registries, etc.)
• Copying signatures to syndicated repos.