Add support for setting error type via ProducesResponseType attribute

[captainsafia]

Addresses #7874.

We set the default error type depending on whether or not the user has set the SuppressMapClientErrors option (ref). When the option is not configured, we set the default to typeof(ProblemDetails).

This default gets set via an implicit ProducesErrorResponseType attribute on all controllers (ref) and ultimately gets consumed for APIs that produce an error type designated as a client error (ref).

Based on the bug reports associated here, this is not the desired behavior. So to work around that I:

• Added an opt-in OverrideDefaultErrorType flag to the ProducesResponseType attribute
• Added some logic in the ApiResponseTypeProvider to avoid using the default error type if the above flag is set

I chose this approach because:

• I wanted to reduce the impact of the breaking change so I made the new strategy opt-in instead of opt-out
• I wanted to localize the setting to the affected attributes

[captainsafia]

Open to alternative ideas for names here. My creativity puttered and this was the most explicit name that I could come up with.

[pranavkm]

I think I'll play around with this to get a sense for the bug. Declaring the error behavior here is too far disconnected from the implementation that configures one to make sense.

[captainsafia]

Another approach is to change the below:

aspnetcore/src/Mvc/Mvc.Core/src/ApplicationModels/ApiBehaviorApplicationModelProvider.cs

Lines 45 to 46 in b98bcea

	var defaultErrorType = options.SuppressMapClientErrors ? typeof(void) : typeof(ProblemDetails);

to read from an option other than SuppressMapClientErrors.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[javiercn]

nit: Extra line

[javiercn]

In which situations do you think the old-behavior is useful? From what I understand, the issue is that if an action returns void, the response in swagger is changed from no content to "this operation returns ProblemDetails"

[SteveSandersonMS]

If I'm reading this correctly, the flag means the opposite of what the sentence above implies. That is, true means we use the explicitly-provided one, and false means we use the global one. Also typo in "explicitly".

Suggested change

	/// Gets or sets whether or not the default error type should be used when one
	/// is expliclty provided as a type in the <see cref="ProducesResponseTypeAttribute"/>.
	/// Gets or sets whether or not the default error type should be overridden when one
	/// is explicitly provided as a type in the <see cref="ProducesResponseTypeAttribute"/>.

[captainsafia]

Closing in favor of an alternate approach.