invent a way to refer to additional manifest annotations via a URI

[tych0]

Right now, we are using tools like containers/image to transport images and umoci copy viz. #359 will be awesome to use to replace this.

One problem we have with containers/image is that it can't refer to any annotations besides org.opencontainers.image.ref.name, so we end up adding lots of metadata there and parsing it with ugly hacks insteading using something more structured like e.g.additional annotations on the manifest tha
t org.opencontainers.image.ref.name points to.

What would be awesome is if we could select images based on some URI; for
example:

umoci copy "oci:myimage?com.cisco.product.version=x.y.z&com.example.other .annotation=foo" $dest, which would select all images that have both name == myimage and match the other annotations too.

We could add some flags like umoci copy oci:myimage --addl-annotation com.example.other.annotation=foo $dest, but it does seem useful to be able t
o refert to an image with a single URI.

Thoughts?

[cyphar]

Resurrecting this -- we discussed this back in 2017 when we switched to org.opencontainers.image.ref.name (from the old refs directory model) and the suggested "right" way of doing this was to create a UX somewhat akin to SQL statements but AFAIK nobody has actually done that so we don't really have a good example to reference.

I think the ideal solution would be:

1. For operations where it makes sense to support multiple matching images (umoci stat, umoci rm), we can just accept multiple matches (maybe for umoci rm we would want to have confirmation that the user wants to remove multiple images).
2. For operations where only it only makes sense to operate on one image, we could have an interactive mode where you pick which image you want (obviously with a --non-interactive flag that would be auto-set for non-console /dev/stdin which would cause us to error out).
3. And yes, we need to have some method for unambiguously matching multiple parameters. I think this would also dovetail quite nicely with Support images without tags #511 (in that case we want to reference images by hash directly). I wonder what the right API would be though. The ?... approach you suggested makes sense, I guess...