Avoid applying null semantics expansion to joins between composite keys

[divega]

In the discussion at #15798 (comment), we agreed that we will stick to the principle that when we traverse relationships (essentially, performing an equality comparisons between keys), null values should not be considered equal, therefore we should not use null semantics.

This principle applies to anything generated by navigation expansion, as well as to ad-hoc relationships established by join operations.

In LINQ to Objects, Join() for simple keys follows this same rule: two values of a nullable type that are null are not considered a match. But for anything more complicated, Join() relies on the equality comparer at hand, which is usually implemented using null semantics. For examples, a join between new {A = 1, B = null} and new {A = 1, B = null} is a match because the comparer of anonymous types just performs member by member comparison with client null semantics.

Join between composite keys in LINQ usually ends up being represented as joins between structural types, and hence when we translate them to SQL, we currently go out of our way to try to replicate the behavior of LINQ to objects.

I believe that doing so can produce unnecessarily complex queries and also results that don't align with how composite key joins normally work on databases.

[maumar]

this is fixed now