Add more utilities to handle common layer creation scenarios

[sambhav]

It would be useful to have some handy utilities to compare layer metadata and "reset" layers when they don't match.

For eg. something like this is implemented in libpak via a new layer contributor. Maybe we should consider adding something similar to libcnb as it feels like a fairly common and generic use case.

FWIW the python version of libcnb which heavily borrows ideas and Apis from this go version has some similar utilities for layer metadata comparison, loading the metadata and resetting the layer https://samj1912.github.io/python-libcnb/api/#libcnb._layers.Layer for an idea of what this could look like in libcnb

[loewenstein]

@samj1912 is this in the 2.0 milestone because it cannot be done in 1.x or because it is a requirement to release 2.0?

cc @dmikusa

[dmikusa]

Historically we've kept libcnb to be just a thin layer over the spec. Adding some higher-level primitives would be a change from that. We also removed layer contributors in v2, so we've moved even more in that direction.

I'm not against adding some higher-level primitives, but I think we'd want to have a plan laid out on what those are and get some agreement in that direction (not sure a full RFC is needed, but something close to that).

Side note, because we use layer contributors at Paketo, I've implemented them in libpak. If someone is missing those, you can use libpak as an easy way to migrate to v2.

I wouldn't mind moving some of what we have in libpak into libcnb either. I think there are some genuinely useful primitives in libpak that we could share. I think there are also probably more high-level patterns that we could institute that would allow folks to more quickly and more easily author buildpacks, but not layer contributors. I have mixed feelings about layer contributors.

Anyway, I'm going to leave this open, but unless we get some feedback on this issue with things folks want to see, I'm not sure this is going to go anywhere.