Move System.Object serialization to ObjectConverter

[eiriktsarpalis]

Continuing the backporting efforts of #54420, this PR brings a change from #54328 that requires review in isolation:

Potential breaking change

The changes introduce a deliberate breaking change when it comes to the handling of new object() values. The existing implementation will hardcode the serialization to {} even if the user has subscribed a custom JsonConverter<object> that does something different. I would like to change this behavior for a few reasons:

• It can be surprising to users: custom object converters cannot be polymorphic with the sole exception of new object() values. Users cannot specify a custom serialization format for new object() values.
• Keeping it requires maintaining more complex logic in the serialization hot path. The change makes the code simpler by delegating object instance serialization to the relevant converter.
• It is unlikely that new object() instances are being serialized in production applications.

The breaking change concerns the following scenario:

using System;
using System.Text.Json;
using System.Text.Json.Serialization;

var options = new JsonSerializerOptions { Converters = { new CustomObjectConverter() } };
string json = JsonSerializer.Serialize(new object(), options);
Console.WriteLine(json);

public class CustomObjectConverter : JsonConverter<object>
{
    public override void Write(Utf8JsonWriter writer, object value, JsonSerializerOptions options) => writer.WriteNumberValue(42);
    public override object Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options) => throw new NotSupportedException();
}

In .NET 5 the above would print {}, however under the new changes it would print 42. This could break users with custom object converters who rely on the existing hardcoding behavior.

[ghost]

Hello @eiriktsarpalis!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 10 minutes. No worries though, I will be back when the time is right! 😉

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[ghost]

Tagging subscribers to this area: @eiriktsarpalis, @layomia
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Continuing the backporting efforts of #54420, this PR brings a change from #54328 that requires review in isolation:

Potential breaking change

The changes introduce a deliberate breaking change when it comes to the handling of new object() values. The existing implementation will hardcode the serialization to {} even if the user has subscribed a custom JsonConverter<object> that does something different. I would like to change this behavior for a few reasons:

• It can be surprising to users: custom object converters cannot be polymorphic with the sole exception of new object() values. Users cannot specify a custom serialization format for new object() values.
• Keeping it requires maintaining more complex logic in the serialization hot path. The change makes the code simpler by delegating object instance serialization to the relevant converter.
• It is unlikely that new object() instances are being serialized in production applications.

The breaking change concerns the following scenario:

using System;
using System.Text.Json;
using System.Text.Json.Serialization;

var options = new JsonSerializerOptions { Converters = { new CustomObjectConverter() } };
string json = JsonSerializer.Serialize(new object(), options);
Console.WriteLine(json);

public class CustomObjectConverter : JsonConverter<object>
{
    public override void Write(Utf8JsonWriter writer, object value, JsonSerializerOptions options) => writer.WriteNumberValue(42);
    public override object Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options) => throw new NotSupportedException();
}

In .NET 5 the above would print {}, however under the new changes it would print 42. This could break users with custom object converters who rely on the existing hardcoding behavior.

Author:	eiriktsarpalis
Assignees:	eiriktsarpalis
Labels:	area-System.Text.Json, auto-merge
Milestone:	6.0.0