It is my understanding that our deppy implementation for OLM is structured to align well with OLMv0's GRPC ListBundles API. This API essentially folds the various FBC APIs into a single api.Bundle type, which represents a bundle in a channel.

This GRPC API is not going to stick around in OLMv1, so I suggest that we re-align the deppy implementation for OLM to decouple bundles and channels. I'm not super familiar with the inner workings of deppy and the entity source API, but my high level thought is that we could essentially have multiple sources of variables: bundles and channels.

If someone specifies spec.version, we would look at bundles to generate resolver variables. If someone specifies spec.channel we look at channels to generate resolver variables.

I sort of imagine mapping FBC schemas to deppy variable sources. That way, if and when we introduce new FBC schemas, it is conceivable that teaching deppy about that schema is simply a matter of implementing another variable source that understands that schema.

Overall, this need will become more apparent as part of the catalogd integration. With the OLMv0 catalog source, the ListBundles GRPC API returns multiple bundles with the same CSV name that reference the same image, but differ only by channel and upgrade edge information. In catalogd, the BundleMetadata API returns unique CSV names, and channel information comes from the Package API.

My expectation is that the initial catalogd integration covered by #161 will generate entities as deppy currently expects them (i.e. duplicate CSV name bundles, one for each channel the bundle shows up in). And then when we get around to this issue, we would simultaneously change the deppy expectations and the catalogd integration.