[DO NOT MERGE] Multi arch containers

[surayya-MS]

The changes in this PR:

1. PublishContainer target renamed to _PublishSingleContainer
2. New _PublishMultiArchContainers target that calls _PublishSingleContainer for each arch and then creates image index
3. PublishContainer target calls either _PublishSingleContainer or _PublishMultiArchContainers depending on a condition
4. Implemented new task CreateImageIndex that creates the image index (manifest list it's same thing) and pushes to the remote registry.

Notes:

• For docker in order to create manifest list (image index) the images must be available in the remote registry. For podman it is possible to do it locally. That is not part of these PR. It will be the next iteration.
• Another thing that needs to be done is reordering of targets and trying to call _PublishSingleContainer target in parallel
• Unit tests

Testing:
Tested manually for docker hub registry, linux-x64 and linux-arm64 architectures

[baronfel]

A few notes that we will need to handle based on my trials at baronfel/sdk-container-demo#15

• The ContainerRepository property is only inferred for single-RID scenarios, not multi-RID so the CreateImageIndex task crashes.
  • We should be able to infer this property similarly to how we infer it for the single-RID publishes
• ContainerImageTags needs to be supported for the inner builds - when ContainerImageTags is specified we get crashes on the single-image Publishes because the single-image publishes unconditionally forward along a single tag.
  • Instead of always forcing a single ContainerImageTag, we should append the RID to each ContainerImageTags value if specified
  • The CreateImageIndex Task should also accept ContainerImageTags similar to the single-image push
• Using the package is rough right now - the in-SDK checks complain at you. In addition, if you have both the SDK and the package the SDK's Import always overrides the package. I had to work around this here
  • We should set the _ContainersTargetsDir property to point to the containers package path in the package .props so that users don't have to do all of this
  • We should add a Code to the Containers-checking target to allow users to suppress this warning - we can steal the code from my older PR: Add code to containers check to allow users to silence it #42501
• CreateImageIndex crashes when no container registry is specified, often because a local publish was done
  • we should add a Condition that skips CreateImageIndex when local daemon publish was requested

[KalleOlaviNiemitalo]

PublishContainer target calls either _PublishSingleContainer or _PublishSingleContainer depending on a condition

Or _PublishMultiArchContainers.

[baronfel]

These three Items can't be 'passed' into the inner build like this because they contain metadata that gets removed when they are converted back to properties. As a result, when parsed back into Items during _ParseParametersForPublishingSingleContainer the Items exist but no longer have any of their useful values.

@rainersigwald is there a better pattern for computing properties and Items that should be provided to an Inner build?

[rainersigwald]

There's not really a good "push" model for items with metadata. You can "pull" via the return value of a target called with MSBuild; that might be an option here (to have the inner builds call back to the outer build to get the info). Otherwise you have to pass structured data and deserialize it on the other side (JSON or something).

[baronfel]

this is an interesting question though - you could see for some of these (env var/arguments) might need to vary per-RID.

[baronfel]

I tested the next round of changes and it's looking really good!

• ContainerRepository now works for the outer build
• ContainerImageTags is working as expected for the outer and inner builds
• The 'skip publishing an Image Index' is working great when publishing multiple images to local sources (Podman manifest support will come later)

I noted two problems to dig into:

• The labels, env vars, and ports are not correctly being passed into the inner builds because data is lost in the current transmission format. I don't know a good answer for this off the top of my head, so I pinged Rainer for guidance.
• the generated manifests use the docker distribution list media type - but this needs to be configurable. The specs for each of the two 'list' types declare what they allow:
  • Docker Manifest Lists allow application/vnd.docker.distribution.manifest.v2+json and application/vnd.docker.distribution.manifest.v1+json
  • OCI Image Indexes use [application/vnd.oci.image.manifest.v1+json](https://github.com/opencontainers/image-spec/blob/main/manifest.md)
  • so we will need to pick one based on what the mediaTypes of the individual base images are (which we can collect from the results of the per-image builds)