Allow for images with artifacts layers to pull and run

[jsturtevant]

This allows images that might have additional artifacts or no layers to pull content and still start properly. This follows the same pattern as in the transfer service: https://github.com/containerd/containerd/blob/main/pkg/unpack/unpacker.go#L188

Without this change you get mismatched image rootfs and manifest layers at the import and run steps. This isn't really true as the layers and manifest layers can match and while potentially still having other layers that would correspond to artifacts.

Background

After several iterations of working with OCI artifacts for WASM with #8699 and feedback from users trying it out on runwasi, it was determined that the minimal number of changes to containerd would be beneficial so we could potentially use this in containerd today (via backport).

Some tests in runwasi are using this branch to validate pulling oci artifact containerd/runwasi#147

[k8s-ci-robot]

Hi @jsturtevant. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[neersighted]

It's worth noting that the comment is slightly incorrect; these are just layers with unknown mediaTypes and are not necessarily artifacts; indeed, I don't think containerd should try to treat an artifact as an image in the default case.

I've opened a PR against the image-spec to try and clarify this at opencontainers/image-spec#1141; assuming it is accepted, I'll try to touch up this comment in a PR that ignores artifacts (as defined by that PR) unless they match a list of known supported types (read: none at this time).