Add parameterless overload for RequireCors API

[captainsafia]

Background and Motivation

The RequireCors extension method is an imperative style API designed to be used in conjunction with endpoints as an alternative to the EnableCors attribute.

At the moment, the RequireCors method provides two overloads:

• One that takes a policy name as a string parameter
• One that takes a policy builder as a parameter

At the moment, there is no way to invoke RequireCors with the default behavior that is available in the EnableCors attribute as mentioned here since the invocation would be ambiguous between the two overloads:

app.MapGet("/", () => "Hello world!")
  .RequireCors(null); // Ambiguous between string or Action overload

Proposed API

namespace Microsoft.AspNetCore.Builder;

public static class CorsEndpointConventionBuilderExtensions
{
+  public static TBuilder RequireCors<TBuilder>(this TBuilder builder) where TBuilder : IEndpointConventionBuilder
}

Usage Examples

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddCors();

var app = builder.Build();
app.UseCors();

app.MapGet("/", () => "Hello world!")
  .RequireCors(); // Uses CorsOptions.DefaultPolicyName

app.Run();

Alternative Designs

• Require users to use the pre-existing EnableCors attributes on endpoints to get the desired behavior

[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.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[BrennanConroy]

API Review Notes:

• Makes sense, I have no concerns/questions

API Approved!

namespace Microsoft.AspNetCore.Builder;

public static class CorsEndpointConventionBuilderExtensions
{
+  public static TBuilder RequireCors<TBuilder>(this TBuilder builder) where TBuilder : IEndpointConventionBuilder
}