Make resolver GetTypeInfo methods return new instances on every call

[layomia]

Fixes #76535.

[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 #76535.

Author:	layomia
Assignees:	layomia
Labels:	area-System.Text.Json
Milestone:	7.0.0

[eiriktsarpalis]

Nit:

Suggested change

	=> {GetTypeInfoCoreMethodName}({TypeLocalVariableName}, {OptionsInstanceVariableName});
	=> {GetTypeInfoCoreMethodName}({TypeLocalVariableName}, {OptionsPropertyName});

[eiriktsarpalis]

This is a good change overall, but it will introduce susbtantial performance regressions in all serialization methods accepting JsonSerializerContext (since metadata will be created from scratch on each operation).

Possible alternatives:

1. Take Ensure source generated metadata properties are read-only. #76540 instead so that JsonSerializerContext.GetTypeInfo returns the same instances but guarantee that those are read-only. Note that IJsonTypeInfoResolver would still return fresh mutable instances to guarantee compositionality.
2. Update the implementation of JsonSerializers's JsonSerializerContext resolution logic so that metadata is looked up via the JsonSerializerOptions cache. Note that the standard JsonSerializerOptions.GetTypeInfo* methods will return NotSupportedException on missing metadata instead of InvalidOperationException so some adjustment might be required there.

[eiriktsarpalis]

Update the implementation of JsonSerializers's JsonSerializerContext resolution logic so that metadata is looked up via the JsonSerializerOptions cache.

On that note, it appears that this approach has the potential of interacting with the reflection fallback compatibility switch that was recently added. TL;DR if the compatibility switch is enabled, it would most likely result in reflection metadata leaking into JsonSerializerContext serialization methods -- a regression from .NET 6.

[eiriktsarpalis]

@layomia I pushed commit eiriktsarpalis@240a24c in my fork of your PR branch which demonstrate how we could keep using cached metadata in the JsonSerializerContext serialization overloads without regressing any functional tests. PTAL and incorporate in your PR as necessary.

[layomia]

On that note, it appears that this approach has the potential of interacting with the #75615 that was recently added. TL;DR if the compatibility switch is enabled, it would most likely result in reflection metadata leaking into JsonSerializerContext serialization methods -- a regression from .NET 6.

Yeah can confirm this happens; I noticed reflection-fallback test failures in an earlier iteration of this PR when taking this approach.

@layomia I pushed commit eiriktsarpalis@240a24c in my fork of your PR branch which demonstrate how we could keep using cached metadata in the JsonSerializerContext serialization overloads without regressing any functional tests. PTAL and incorporate in your PR as necessary.

I agree this would be the right way to mitigate the performance hit from this change were we to go down the path this PR proposes. But the solution in #76540 is more complete and less breaking so I'll close this in favor of that approach.