Add relational JSON mapping support for complex types

[AndriySvyryd]

• Model building and validation
  • Toplevel collection and non-collection complex types mapped to JSON as well as nested
  • Allow configuring the column type with ToJson() (e.g. NVARCHAR(MAX) vs. the new JSON type). Also optionally look at pre-convention configuration support for bulk configuring the default (less important).
  • Map the discriminator property to $type in JSON by default
  • Add table mappings for nested complex types
• Relational and compiled model support
• Migrations support
• Update pipeline support
  • SaveChanges over complex JSON types with partial updates #36429
• Complex JSON query support #36296,

[Timovzl]

If the property being mapped here is a collection [of value objects], perhaps structural equality should be preferred on the collection. The value objects inside can simply override Equals() et al, but that is not as feasible for the collection holding them.

[roji]

@Timovzl structural equality is definitely planned for the collections, just as it already works for the complex types themselves. However, in change tracking EF doesn't compare complex types to one another directly (e.g. via their Equals), but rather compares the properties contained in the complex types (since it needs to know which properties changed).

[aradalvand]

Already the second most upvoted open issue in the repo in just over 4 months 😅 People seem to really want this!

[roji]

@atrauzzi I don't follow all of the above, but EF's implementation here will definitely not simply be System.Text.Json's polymorphism capabilities (nor will it magically recognize your own hand-rolled [JsonPolymorph]). As explained in #31250, this will very likely end up being EF modeling the inheritance hierarchy and discriminator (just like it already does with TPH), and implementing JSON serialization/deserialization via the low-level Utf8JsonReader/Rwriter (just like we already do with owned entity JSON support).

In any case, this really doesn't belong on this issue, but rather on #31250 - I'll hide these comments to keep things clean.