Added ReferenceResolverProvider to JsonSerializer to allow safe caching

[TylerBrinkley]

Fixes #1391
Fixes #1452
Fixes #870

[JamesNK]

The reason I left JsonSerializer with a property that returns IReferenceResolver is the property can be used inside a JsonConverter's WriteJson/ReadJson (each has a JsonSerializer parameter). A func that returns a new instance each time will break people who want to use the resolver inside a converter.

[TylerBrinkley]

Hmm, could ReferenceResolver be added to JsonReader and JsonWriter instead which are both available to JsonConverters?

[JamesNK]

No. References are specific to serialization.

[TylerBrinkley]

It seems to me that JsonReaders and JsonWriters are not used concurrently and thus would work well to expose the currently used IReferenceResolver. As such I've updated the pull request to support that.

Basically, it's either this or JsonSerializers aren't safe to reuse if references are used.

[TylerBrinkley]

Hmm, maybe we could use a JsonSerializerProxy for each serialization call to pass to JsonConverters whose ReferenceResolver property is specific to that serialization call? Then we wouldn't need to add ReferenceResolver properties to JsonReader and JsonWriter and current JsonConverters will continue to just work. To ensure JsonSerializerProxy remains lightweight we could consider moving all of JsonSerializer's fields to a private settings class so that JsonSerializer only has one field which won't be used for JsonSerializerProxy.

[TylerBrinkley]

I just implemented what I proposed above. It looks like a JsonSerializerProxy was already being passed to JsonConverters so no changes needed there.

[TylerBrinkley]

I just realized you baked your DefaultReferenceResolver's state into JsonSerializerInternalBase's DefaultReferenceMappings property. The only state that is not baked in is the reference count hence the creation of #1391. As opposed to baking the reference count into JsonSerializerInternalBase it seems like the right thing to do in this situation would be to move DefaultReferenceMappings into the resolver itself and use the changes I have made. This way custom IReferenceResolvers will work just as well as the DefaultReferenceResolver.

This has been implemented in the PR.

[TylerBrinkley]

Resolved merge conflicts

[TylerBrinkley]

@JamesNK Please review when you have the time. Thanks.

[Terebi42]

I am experiencing this bug in production, please accept this PR

[dtila]

This PR does not fixes the issue, so don't merge.
There is still an issue with the threading and the bidirectional mapping. The first equality comparer is the default, and the second is a reference only. For class files, it will causes an unbalanced dictionary for classes implementing IEqutable.

[TylerBrinkley]

Closing due to age.