Remove (Http)(Validation)ProblemDetails converters

Hi, I think this may be related, but the casing for ProblemDetails is also inconsistent. ProblemDetails itself defaults to camel case, but as you can see above when describing the “Summary” field, it’s capitalized. Shouldn’t that be lower case, assuming @TanvirArjel is using the default naming policy?

I’ve also noticed ProblemDetails does not obey JsonOptions settings, e.g., setting

services.Configure<JsonOptions>(opt =>
{
    opt.JsonSerializerOptions.PropertyNamingPolicy = null; // don't convert to camel case
});

should give a response like

{
    "Type": "https://tools.ietf.org/html/rfc7231#section-6.5.4",
    "Title": "Not Found",
    "Status": 404,
    "Detail": "Account 1 not found.",
    "TraceId": "00-50f63c5d7921484e4797d82687f43033-915b95474bf55ff2-00"
}

but it does not, at least from what I can tell. Maybe this is by design since the spec (https://www.rfc-editor.org/rfc/rfc7807) explicitly lists the properties lower/regular camel case, but it also doesn’t seem to explicitly call out camelcase must be used. I think anyone who is using problem details should be able to use whatever casing their API uses already rather than being forced to either a) have inconsistent casing returned or b) use camel case.

_Originally posted by @jchoca in https://github.com/dotnet/aspnetcore/issues/43261#issuecomment-1248777800_

Repro:: https://github.com/jchoca/ProblemDetailsJsonSettings

[eiriktsarpalis]

Your example happens to work because you’re prepopulating the dictionary on the property. If I change the POCO to

public class ProblemDetails
{
    [JsonExtensionData]
    [JsonInclude]
    public IDictionary<string, object>? MyProperty { get; } = null;
}

Then your app will immediately hit the exception produced by the source generator.

The function of JsonIgnoreAttribute is to instruct the serializer to bypass accessibility modifiers and try to use private or internal property setters, if available. It predates the source generator and is generally speaking problematic when used in conjunction with it. I would recommend removing it altogether and exposing a property setter that the serializer can readily use.

[khellang]

IMO, the right thing to do for JsonExtensionData would be to follow PropertyNamingPolicy as the fact that it’s implemented as a .NET dictionary is just an implementation detail. From a JSON POV it’s just a bag of properties. Unfortunately that issue has been shut down due to round-tripping concerns; https://github.com/dotnet/runtime/issues/31167