Add image.UnparsedInstanceWithReference and storage.ResolveReference

[mtrmac]

We need to implement this locally, instead of having external callers do it, because external wrapping would make the sigstore-relevant UntrustedSignatures unavailable.

See conversation in cri-o/cri-o#7046 .

[mtrmac]

Also adding storage.ResolveReference, so that something like this is possible:

ref := ParseReference(userInput)
ref2, img := ResolveReference(ref)
src := ref2.NewImageSource

while ensuring that img and src are guaranteed to refer to the same image.

@vrothberg PTAL; ResolveReference might be relevant to how c/common/libimage.Runtime.storageToImage maintains both *storage.Image and types.ImageReference for “the same” image. lookupImageInLocalStorage sort of does that manually, but that seems to lose the original name — i.e. it might then not use the manifest with the requested manifest digest.

---

Temporarily includes #2147 , so that ResolveReference can be tested. That will either go away, or be incorporated properly, depending on the outcome of that other PR.

[vrothberg]

Thank you!

[mtrmac]

This is now ready for review/merging.

cri-o/cri-o#7435 is a proof-of-concept of the ResolveReference use (in internal/storage.imageService.imageStatusByName)

[rhatdan]

LGTM

[flouthoc]

With deprecation of these API CI is forcing podman and buildah to use ResolveReference which is nice !. But it seems that error behavior of ResolvedReference is not same as GetStoreImage. Where GetStoreImage returned storage.ErrImageUnknown but ResolveReference return a formatted error for the same use-case https://github.com/containers/image/blob/main/storage/storage_reference.go#L303 which is not same as previous behavior.

For buildah side (containers/buildah#5129) I have edited changed the code but I wonder if this is a breaking change ?

[flouthoc]

@mtrmac ^ Is this something which is breaking change ? or am I just overthinking here.

[mtrmac]

Oh, yes, I forgot to document that here.

It’s not a breaking change because ResolveReference is a new API, and the behavior of the old one didn’t change (AFAIK), but it is very surprising and the deprecation notice should document that.

[mtrmac]

Alternatively, we could change the error type back… but on balance, I think returning a c/image/storage-defined error type is a bit cleaner than returning a c/storage-defined one (although the c/image one is actually an alias).

[mtrmac]

#2170 should help with the documentation, and/or change the returned error types.