Snapshotter with caching

[apostasie]

This is a proof of concept / draft for #3027

Average, very un-scientific measurements fornerdctl images:

On 500 identical images at 270MB:

• without cache: 5.2 seconds
• with cache: 3.3 seconds

On 500 identical images (buysbox, one layer, 4.174MB):

• without cache: 5.0 seconds
• with cache: 4.8 seconds

For about 250 containers (nerdctl ps -as) started from the same image (the big one above), results are in the same ballpark: about 50% gain with cache.

This PR also consolidates code and reduce duplication I did introduce...

Let me know if this is something we should consider.

If yes, we can iterate on design / code location and possibly simplify the signature of imgutil.SnapshotServiceWithCache for eg.

[apostasie]

May have an impact on #809 and #325 when a lot of layers are shared.

[ktock]

snapshots.Info.Updated might be updated. I think this can't be cached.

[apostasie]

Hey @ktock ! Thanks for looking at this.

The snapshotter here is NOT meant to do caching across successive calls.

This is meant solely to be used when calling things like image list and walking through the resulting collection of images, and NEVER for two successive, separate in time, calls on the same resource.

Furthermore, there is no persistent caching mechanism - same reason.

[ktock]

Thanks for clarification. At least it should be documented that this should be used only for short term usage.

But why does it wrap the entire snapshotter API whereas it only patches Stat and Usage? I think this doesn't need to be a wrapper for the entire snapshotter and can be implemented at the caller.

[apostasie]

You welcome! Yes, I will document.

As for the other question: it does implement the Snapshotter interface so it can easily be swapped in / out in place of the containerd snapshotter.
Of course we can just implement a smaller struct, but that would change the signature.

I am fine with either approach, so, let me know what do you folks prefer here.

[ktock]

Of course we can just implement a smaller struct, but that would change the signature.

SGTM

[apostasie]

@ktock I am closing this in favor of #3029 which is no longer a draft and has a complete, cleaner version and caching optimizations that can benefit any method dealing with bulks of objects (ps, images).