Don't maintain URLs for foreign layers when pushing them

[drcapulet]

For images with non-distributable layers, if we're pushing the layer to the destination we want to remove any URLs on the layer since they're generally preferred over the repository itself (containerd example) - this is important for deployments to air-gapped installations that don't have access to any of the URLs.

[mtrmac]

Thanks for the PR.

AFAICS c/image is, currently, falling back to using the registry if the external URL is unavailable. Though it does look that that’s not the case for containerd, and it seems to be unintentional for c/image.

It’s not clear to me that this is a behavior we can just change; it might need a separate option.

---

Note to self: The documentation for DownloadForeignLayers says that MIME types are updated, and I can’t see how that happens (nor, actually, whether it is desirable).

[drcapulet]

@mtrmac Appreciate the review - funny enough the day I opened this Microsoft dropped the usage of foreign layers, I'm inclined to just close this out?

I can't personally tell on the expected behavior for URLs from the spec.

[mtrmac]

I do think you’ve touched on a feature gap and/or a bug, and it’s worth fixing in principle.

OTOH the real-world need for the foreign layer feature is really becoming much less urgent. If you want to close this PR, I think that’s completely fair.

[jankaluza]

Hi, and thank you for your contribution!

We’ve recently migrated this repository into a new monorepo: containers/container-libs along with other repositories

As part of this migration, this repository is no longer accepting new Pull-Requests and therefore this Pull-Request is being closed.

Thank you very much for your contribution. We would appreciate your continued help in migrating this PR to the new container-libs repository. Please let us know if you are facing any issues.

You can read more about the migration and the reasoning behind it in our blog post: Upcoming migration of three containers repositories to monorepo.

Thanks again for your work and for supporting the containers ecosystem!