Set operations: allow operands with different entity types

[roji]

Our current set operation support requires that both siblings have the exact same entity type. Quite a lot of logic is already in place for different entity types (of the same hierarchy), but the feature is currently disabled.

The issue is that when performing a set operation over two different siblings, null projections have to be injected, as the two siblings don't have the same set of properties. In addition, since the entire set operation is cast up to return the closest common ancestor of the two siblings, we also need to inject nulls for properties of unrelated siblings, since the shaper expects them there.

We currently lack a way to represent these null constants in the projection mappings of the set operation. Project mappings typically contain ColumnExpressions, but in our case there is no subquery table alias (since union operands don't have an alias). This should no longer be an issue after #17340.

[snailcatcher]

@roji Will this be fixed in the 3.0 release?

[roji]

@snailcatcher unfortunately no, this has been punted for post-3.0 work, but we'll definitely consider this as a high-priority item for the next release.

However, note that you can still perform any sort of set operation on the client via client evaluation - simply insert an AsEnumerable() before performing your set operation. This is how all set operations were handled in pre-3.0 versions, and depending on the exact use case client evaluation may perform just as well as server evaluation (e.g. if no filtering is applied afterwards and all results are sent to the client anyway).