local should use ggcr v1.Daemon

[micahyoung]

ggcr's Daemon implementation appears to now support daemon.Image and daemon.Write and appears that we could use it for the local implementation. If the daemon package has feature-parity with remote, I believe we could get many benefits from using daemon:

• Enable daemons to "pull" non-container-images (ORAS) or otherwise unpullable images, by dynamically rewriting remote-image metadata and/or layers before saving to the daemon during a pull.
  • This looks like it will be important for enabling buildpackages on Windows, which now require a Microsoft-proprietary base-layer for them to be stored on the daemon.
• More shared code between remote and local - perhaps eventually a single implementation with flags for remote/local.
• Use an upstream implementation to which Docker is more directly concerned with supporting.

daemon package: https://github.com/google/go-containerregistry/tree/master/pkg/v1/daemon

[ekcasey]

@micahyoung We moved away from the ggcr daemon implementation awhile ago due to performance issues. Specifically the ggcr daemon package requires us to export and import base layers that already exist in the daemon. Our implementation has shortcut logic that avoids this. AFAIK this issues has not been addressed in ggcr yet

background:
google/go-containerregistry#205
google/go-containerregistry#558

[micahyoung]

Oh, thanks for the background, I totally missed that before. I'll keep an eye on that PR. Thanks!