chore: drop kaniko dependency

[mzihlmann]

Summary

Hi 👋

Full disclosure, I maintain osscontainertools/kaniko, a competing kaniko fork.

pack imports one function from kaniko, to ask whether it is running in a container:

pkg/client/build.go:60         proc.GetContainerRuntime(0, 0) != proc.RuntimeNotFound
pkg/cache/volume_cache.go:133  proc.GetContainerRuntime(0, 0) != proc.RuntimeNotFound

it uses none of the core features of kaniko and as such I think it should not depend on it and rather inline that single function.

Documentation

• Should this change be documented?
  • No

Related

@alphanota found this in #2508. That PR switches fork, which clears the duplicate but keeps a dependency pack does not need. This one removes it.

kaniko does not leave the graph, and is not meant to. lifecycle applies Dockerfiles with it for image extensions, and moved to osscontainertools/kaniko at v0.21.17. pack pins lifecycle v0.21.0, which still carries chainguard-dev/kaniko, so after this go list -m all | grep kaniko still shows that one, at v1.25.5 rather than v1.25.16 now that lifecycle's floor is the only one left. Bumping lifecycle then leaves you with one fork instead of two.

go list -m all on current main, for each option:

	today	switch (#2508)	inline (this)
lifecycle v0.21.0	566, one fork	567, both forks	540, one
lifecycle v0.21.17	559, both forks	553, one fork	528, one

Switching leaves pack importing a kaniko package, so Go keeps loading kaniko's own requirements and the GCP, envoy and spiffe modules stay in the graph. Not importing it prunes them.