Update the image source to not be Kubernetes-centric

[everettraven]

Currently, the image source for unpacking bundle images requires the use of Kubernetes and embeds a lot of, likely unnecessary, Kubernetes specific logic and parameters. The concept of unpacking from bundle images shouldn't rely on the use of Kubernetes and require parameters to adhere to Kuberneteisms.

As an example of why one might not want to require the use of Kubernetes for unpacking the bundle contents, consider a case where someone would like to create a CLI for unpacking bundle contents locally (although currently not feasible due to the unexported unpacking library, but there are various issues that would cause this library to be exported in the future). It doesn't make sense to force someone to have access to a Kubernetes cluster for unpacking the image locally when something like Docker/Podman could be used - or even a Go library such as https://github.com/containers/image or https://github.com/google/go-containerregistry.

[joelanford]

There are two facets here, I think:

1. The image source might still have access to a Kubernetes client to create a pod in a cluster to do the unpacking. However, it is not technically necessary for the image source itself to have knowledge of any potential related objects (e.g. the bundle that initiated the unpacking) to be able to actually unpack the bundle.
2. We can completely remove Kubernetes-isms by changing the image source to talk directly to an image repository.

If we do (2), then (1) is moot because we're no longer creating a pod.

If we do just (1), then we may need to decide how important it is to set an owner reference on the unpack pod and whether there's a way to do it without leaking Kubernetes details in the Unpack abstraction.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.