[Analyzer] Unused route parameter detection and fixer

[JamesNK]

Background and Motivation

When adding a route parameter to a minimal API or action:

1. The route parameter needs to be added to the route
2. .NET parameter needs to be added to the lambda/method.

An analyzer and fixer can automate step 2.

Proposed API

An analyzer inspects the route for route parameters and the lambda/action parameters. If the route has a parameter that isn't present in the lambda/action then the analyzer will suggest a fix.

• Suggestion level (it's valid to have a route parameter that's not used so this isn't a warning)
• Optional route parameter = nullable argument
• Route parameter constraint is used to infer the .NET type. e.g. int constraint = int method parameter. Same with guid, int, long, double, float, datetime, decimal, etc. No route parameter means the new parameter type is string.
• Put the new parameter in the method based on its position in the route.

Usage Examples

Alternative Designs

Risks

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.

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.

[JamesNK]

Double check it works with RequestDelegate overload.

[halter73]

API Review Notes:

• It does seem unusual to define a route value and not take it as a parameter to your delegate.
• This will file a lot on older code using the RequestDelegate overload, but maybe that's okay.
• This will recommend changing to an API that is less trim safe in some cases.

Category: Usage
Severity: Info