Update platform spec to improve performance when restoring launch sboms from daemon

[natalieparellano]

In implementing RFC 0095, we inadvertently made rebuilds much slower on a daemon when the previous image has a launch sbom. For launch layers, the sbom files must be restored to the buildpack layers directory (just like layer.toml files) on the next build; however the sbom files are stored in the previous image's filesystem (instead of labels in the config).

As a result, we need to download from the daemon a single layer from the previous image. However we didn't realize that in order to download a single layer from the daemon, you need to first download ALL layers from the image in order to find the one that you want (see imgutil implementation).

To fix this, we need to pass the -launch-cache to the phase that downloads the sbom. This is currently the analyzer (because the analyzer already has access to the previous image) but we think it would make more sense for this to move to the restorer, so that detect can fail faster if it is going to fail. Therefore we'll also need to add a -daemon flag to the restorer (we only allow cache images if they are on a registry, so this flag doesn't exist yet for restorer). This will require platforms like pack that use the daemon to mount in the daemon socket for restore.

[natalieparellano]

Option 1:
Add to analyzer:

• -launch-cache flag
• -skip-layers flag
  Philosophy: analyzer does "previous image things", restorer does "cache things"

Option 2:
Add to restorer:

• -daemon flag
• -launch-cache flag
  Philosophy: consolidate as much logic as possible in the restorer; analyzer does as little as possible

I'm a bit partial to option 1 as it's slightly less work for platforms and the lifecycle to implement. But in theory either would work.

Note that the performance issue can be fixed for the creator (trusted builder) workflow without platform api changes, see buildpacks/lifecycle#784.

[hone]

My vote is for Option #1 as well.

[jromero]

It looks like this should be closed as per #278. Please re-open if I'm mistaken.