Support use of fast-path serialization in combined JsonSerializerContexts.

[eiriktsarpalis]

Fixes#71933 by adding a new JsonTypeInfo.OriginatingResolver public property that is used by source generated JsonSerializerContext instances to register themselves with JsonTypeInfo instances that they generate. This information can be used to determine if the fast-path serialization delegate is compatible with the current configuration, even if the originating JsonSerializerContext is encapsulated behind a custom resolver.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #71933 by adding a new JsonTypeInfo.OriginatingResolver public property that is used by source generated JsonSerializerContext instances to register themselves with JsonTypeInfo instances that they generate. This information can be used to determine if the fast-path serialization delegate is compatible with the current configuration, even if the originating JsonSerializerContext is encapsulated behind a custom resolver.

NB the new property hasn't been approved in API review yet.

Author:	eiriktsarpalis
Assignees:	-
Labels:	area-System.Text.Json, new-api-needs-documentation
Milestone:	-

[krwq]

Do we actually need new API? I can see at least two ways we can do it without new API:

• not assign SerializeHandler in cases where fast path should not be used - we can move the fast path checking logic to a generated context.
• another option is we wrap every context with combined (as effective resolver, from user perspective they wouldn't know about it). Then combined one could check if all contexts are compatible between each other and with the options. Then combined context can decide if fast path can be used (so rather than checking if resolver is context we check if it's combined resolver and go from there)
  the second option might be easier and should be compatible with contexts generated in previous versions

[eiriktsarpalis]

not assign SerializeHandler in cases where fast path should not be used - we can move the fast path checking logic to a generated context.

That might just work actually. We could remove the runtime invalidation altogether and just decide if the fast path should be assigned at the context layer.

[eiriktsarpalis]

not assign SerializeHandler in cases where fast path should not be used - we can move the fast path checking logic to a generated context.

That might just work actually. We could remove the runtime invalidation altogether and just decide if the fast path should be assigned at the context layer.

Actually, I was wrong about this. We would still need to expose new API but even then this cannot account for contexts generated by older versions of the sdk; we still need to do this invalidation in the JsonTypeInfo layer.

[eiriktsarpalis]

Converting to draft, as more infrastructural changes on JsonTypeInfo are required before we are able to implement proper invalidation.

[eiriktsarpalis]

I've updated the PR and it should be ready for review again. @krwq & @layomia PTAL.

[krwq]

should you be checking IsConfigured here as well?

[eiriktsarpalis]

It could be false if you're configuring recursive types. Checking IsConfigured on JsonPropertyInfo is a different story, it completes regardless of cycles.

[krwq]

should this also check for Modifiers.Count == 0 and GetType() == typeof(DefaultJsonTypeInfoResolver)?

[eiriktsarpalis]

In this case you don't need to, any customization to the particular JsonTypeInfo would get picked up by the IsModified property.