[release/8.0] Fix casing of ProblemDetails for RFC compliance

[captainsafia]

Backport of #53789 to release/8.0

/cc @captainsafia

This PR ensures that property keys that are used in ProblemDetails and ValidationProblemDetails are always in camel-case, regardless of the serialization options in the application as a whole, to provide compliance with the RFC 7807 spec.

Description

In .NET 8, we merged a PR to remove the custom converters used for ProblemDetails and ValidationProbleemDetails in feature of the IgnoreWhenNull attributes that were provided in the box by System.Text.Json.

At the same time, we removed the pre-defined type names that existed on the properties of these types.

As it turns out, this was a bad move. The RFC for problem details is particular about property keys being all lower-case (ref) regardless of what serialization options the rest of the system might be using by default.

This means that are implementation is no longer RFC-compliant. Fixing this by bring backing the explicit type names.

Fixes #53639

Customer Impact

This change breaks the contract provided by the Problem Details specifications. Clients that expect to receive problem details messages that comply with the spec will break if they deserialize with the assumption that our property keys are encoded correctly.

Although there are workarounds to this issue, they involve large amounts of code and we should really provide a correct implementation of the ProblemDetails spec.

Regression?

• Yes
• No

This is a regression from the .NET 7 experience.

Risk

• High
• Medium
• Low

Although the change is localized to the ProblemDetails codepaths in MVC/Minimal APIs, this change is technically introducing a behavioral breaking change in a servicing release. Users who took a dependency on the broken behavior in .NET 8 will be impacted.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @captainsafia. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

[BrennanConroy]

[Long Running Test] 'Microsoft.AspNetCore.Http.Abstractions.Tests.EndpointFilterInvocationContextOfTTests.GeneratedCodeIsUpToDate', Elapsed: 00:14:21

[captainsafia]

[Long Running Test] 'Microsoft.AspNetCore.Http.Abstractions.Tests.EndpointFilterInvocationContextOfTTests.GeneratedCodeIsUpToDate', Elapsed: 00:14:21

Not sure what happened here. 🤔

[ghost]

Hi @captainsafia. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[captainsafia]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[captainsafia]

Approved via tactics.

[captainsafia]

@BrennanConroy @halter73 Can I get a review on this now that it is servicing approved?