Restore cached launch layers not found in appLayers

[pbusko]

Summary

In case if a layer is found in cache and marked as launch = true and cache = true, it will be restored if not found in the appLayers.

This case is possible if -previous-image is not set/found, however a -cache-dir is provided (backed by persistent volumes etc.)

Release notes

---

Related

Resolves #___

---

Context

[loewenstein]

@natalieparellano @jabrown85 Did you have a chance to take a look?

[natalieparellano]

@loewenstein taking a look...

I hate to be that person, but I think this may require a spec change, as the spec is actually quite specific about where the layer metadata comes from: https://github.com/buildpacks/spec/blob/main/buildpack.md#layer-types

That said, having been around when this table was added, I believe its value is simply to clarify how the lifecycle works, as even CNB contributors could not keep track of this behavior. I don't think buildpack authors (or platform authors for that matter) care or need to care where this metadata comes from (maybe we could just update the table to remove that additional detail).

[natalieparellano]

@pbusko I think if you rebase onto the latest main that will fix the Codecov issue

[pbusko]

@natalieparellano unfortunately after rebase the unit tests started to fail on windows platform (is the issue is more general, since #1347 experiences it as well?)

The PR to the spec: buildpacks/spec#406

[natalieparellano]

@pbusko that looks like a flake. We can re-kick it

I hate to be that person, but I think this may require a spec change, as the spec is actually quite specific about where the layer metadata comes from: https://github.com/buildpacks/spec/blob/main/buildpack.md#layer-types

That said, having been around when this table was added, I believe its value is simply to clarify how the lifecycle works, as even CNB contributors could not keep track of this behavior. I don't think buildpack authors (or platform authors for that matter) care or need to care where this metadata comes from (maybe we could just update the table to remove that additional detail).

We talked about this in Working Group today. We agreed that (1) the current level of detail can be removed from the spec, and (2) it's still a behavior change for our platform users and would be better if gated behind a Platform API version bump.

Would you be amenable to this? ^^

[natalieparellano]

This should go in Platform 0.14: https://github.com/buildpacks/spec/milestones/Platform%200.14

(the current issues in that milestone were added long ago and could be kicked out to 0.15 if we want to move this sooner)

[pbusko]

@natalieparellano is there anything blocking this PR and buildpacks/spec#406 from being merged?

[natalieparellano]

@pbusko thanks for the ping - I'll review this today.

[loewenstein-sap]

Needs a second approval? @natalieparellano @jabrown85 ^^