Query: Define set of conditions for materialization on EntityShaper

[smitpatel]

• Entity is not coming from left join, has a key and key value contains null then we throw
• Entity is coming from left join, has a key and key value contains null then return null
• Entity has valid key and is not optional dependent which is sharing same table, then we materialize (this cover required dependents too)
• Entity is optional dependent with table splitting and has a valid key, then we materialize if excluding PK, all of the required columns have value or any of optional column has non-null value else we return null
• Entity is keyless, coming from left join and all properties are null then we return null, we materialize all other keyless entities

In addition to above to support #10140 the flexible mapping condition would become part of it.

EntityShaper will contain a lambda of Func<ValueBuffer, IEntityType>
The lambda returns IEntityType based on above set of conditions telling which entityType to materialize. If there is not entityType should be materialized (e.g. optional dependent), then it returns null. If there is no matching entityType and null cannot be returned (basically unknown discriminator value), it throws exception.

Core EntityShaper contains conditions for discriminator/keyless entityType.
Relational EntityShaper will extend and add conditions for required/optional dependents when table splitting.

@AndriySvyryd - Can you review conditions at the start if that matches what we decided in meeting?

[smitpatel]

Necessary client side component for #18299

[AndriySvyryd]

Looks right, the other thing we discussed was that in some cases we need to determine what shaper to use for the dependent entities that aren't related between them other that being mapped to the same table and the same columns.

• If the principal entities are not being projected we could either use joins to separate them into different columns (current approach, produces more nulls in the reader) or to add a column to the result that would discriminate them (usually the discriminator column for the principal, but could also be a synthesized value).
• If the query also projects the principal entities (the common case) we could materialize the principal first and use the result (specifically its IEntityType) to determine the correct dependent shaper to invoke.
  To support Allow related entities to be passed to constructor of aggregate root #12078 where the dependents are materialized first we would need to either fallback to joins, prevent this kind of mapping in model validation or read the principal column values to determine its IEntityType before materializing the dependents.