fix: skip nil cache result

[jedevc]

Somehow ImmutableRefs can be nil - not 100% sure how this happens, but upstream buildkit does include checks in appropriate places for this case. We should probably do the same as well.

Should hopefully mitigate #6379.

[jedevc]

Ok, in buildkit upstream, we call CacheResultStorage.Load in CacheExporter.Export, and pass it to ResolveRemotes - the functions passed in here call WorkerRef.GetRemotes, which explicitly checks for ImmutableRef being nil: https://github.com/moby/buildkit/blob/8a7e5c73174063ce5482b49b5316e4706534c1d3/worker/result.go#L45-L47.

This check was added in moby/buildkit@1835ef5 (#2434) by @sipsma:

This case happens if you do something contrived like Merge(Diff(Image("busybox"), Image("busybox")), foo), i.e. you do a diff where upper+lower end up being the same ref and thus simplifying to nil, which then gets plugged into merge. Basically, a nil input is treated as Scratch here.

[sipsma]

LGTM, I guess in general this means that we can't currently distinguish between a cache key that has no results and a cache key that explicitly was evaluated and ended up being nothing. The cases where this makes any difference are obscure to start and in those cases the performance hit is so minuscule that I'm inclined to just not care for now.

The reason nil is used for those cases where something evaluates out to be nothing is that the alternative would have been to create an entire snapshot that's only ever going to be empty, which is wasteful in and of itself but would also result in images having unnecessary empty layers, etc.

There's probably some way of addressing that upstream by having a special immutable ref that represents "evaluated to nothing" and handling it all over the entire buildkit codebase, but doesn't feel worth it right now relative to just being aware that a cache ref can be nil.