Ensure the FBC --> entity translation for bundle properties is not lossy

[everettraven]

Currently the translation for catalog contents --> entity is lossy when it comes to bundle properties. As we can see from

operator-controller/internal/resolution/entitysources/catalogdsource.go

Lines 83 to 90 in 80a5786

	for _, prop := range bundle.Spec.Properties {
	switch prop.Type {
	case property.TypePackage:
	// this is already a json marshalled object, so it doesn't need to be marshalled
	// like the other ones
	props[property.TypePackage] = string(prop.Value)
	}
	}

we are only passing through bundle properties that are of type olm.package and therefore losing any other bundle property information.

We should update this to ensure that all bundle properties are being forwarded through during the entity translation so they can be used properly.

[joelanford]

@perdasilva This seems like a rough edge of the translation from FBC to input.Entity. I know the Properties []property.Property field in FBC is problematic, but it seems more problematic that we don't have an opaque canonical translation function.

Another option would be to have input.Entity change its properties field to match (and maybe translate internally)?

Either way, I think we need to smooth out this edge.

[joelanford]

Also, not saying it has to be a deppy concern. This is an OLM-specific thing, so if that translation belongs in operator-controller, that's a-OK!

[m1kola]

Today properties on a Deppy input.Entity are defined as a map of strings. But in operator-controller I think we can pack anything we want into this map in any format we want: we don’t have to change Deppy for operator-controller to understand repeated properties as Deppy itself is not reading properties (but we can consider change to avoid weird marshalling on controller side). And BundleMetadataSpec already has properties as a slice. So to me it looks like the ball is entirely on the operator-controller side.

[perdasilva]

+1 to @m1kola: I think this fix should go in op-controller. Entities are dumb by design. Though, they might go away. I'd say the right way to fix this would be to just laydown a json string in the property - and copy all of the properties over.

[m1kola]

In #413 we got rid of entity source & entity code and now have access to all bundle props, but there is currently an issue on read where we lose some values. Once #427 gets merged, I think we can consider this done.

[m1kola]

#427 is merged now. For some reason GH didn't close the issue, so I'm doing it manually.