Add ReportResolvedSourceReference to copy.Options

[justinmir]

When registry mirrors are configured via registries.conf, callers of copy.Image have no way to discover which endpoint was actually contacted. The source's Reference() always returns the logical (user-requested) reference.

Introduce a ResolvedImageSource interface in types/ that ImageSource implementations can satisfy to expose the physical endpoint. The docker transport implements this by returning its internal physicalRef.

copy.Image populates the new ReportResolvedSourceReference option pointer when the source satisfies the interface, giving callers like CRI-O access to the resolved registry for metrics.

[packit-as-a-service]

Packit jobs failed. @containers/packit-build please check.

[packit-as-a-service]

Packit jobs failed. @containers/packit-build please check.

[mtrmac]

Thanks!

Hum… what should ever really use that value, as a primary implementation matter? [Arguably, c/image should be reporting its own metrics, without CRI-O having to care… we are nowhere near that, nor even slightly moving in that direction currently — but just a matter of “where does this go in the API”, it’s a bit of an argument against exposing it this way.]

What happens if we ever add the option to fall back to another mirror? (OTOH ultimately we can’t avoid hard-coding the concept of a “registry mirror” at some semantic level, of course.)

At a glance, this might be a better fit as a new event (or several?) in the progress reporting channel. That would, even, potentially, allow reporting the attempts to use a mirror (which can take a long time to timeout).

[mtrmac]

If this should happen, please do it in the private types, and non-optional (we use ~mix-ins for the common “N/A” implementations).

[justinmir]

Hum… what should ever really use that value, as a primary implementation matter? [Arguably, c/image should be reporting its own metrics, without CRI-O having to care… we are nowhere near that, nor even slightly moving in that direction currently — but just a matter of “where does this go in the API”, it’s a bit of an argument against exposing it this way.]

+1 agree with this sentiment completely, cri-o shouldn't have to care from an API perspective and metrics in c/image should make much more sense. Given a world where we don't and won't have metrics in c/image for some time, would we be okay with exposing this information to cri-o somehow to expose in its own metrics? I think the progress reporting channel option seems reasonable as well.