Share route pattern parsing logic between analyzers and generators

[captainsafia]

Both the route handler analyzers and the RequestDelegateGenerator share a requirement for being able to parse a route pattern string and extract information about the route parameters in it, constraints on those parameters, etc.

We should identify a way to share this code across the analyzers and generators.

As part of consuming this logic in the RequestDelegateGenerator we want to emit logic that will determine if a parameter appears in the route and sourcing it from the route values dictionary.

cc: @halter73 as this relates to the parameter binding work
cc: @JamesNK who has knowledge in this area

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.

[halter73]

Continuing the conversation from https://github.com/dotnet/aspnetcore/pull/46838/files#r1119362420

Compile-time pattern parsing won't work a lot of the time like when the IEndpointRouteBuilder is really a group with an unknown prefix.

I think our best option is going to be to continue validating the route values during the call to RouteEndpointDataSource.GetGroupedEndpoints(context) like we do in RDF today. Waiting until the RequestDelegate is invoked to throw the InvalidOperationException is too late.

We shouldn't be checking options?.RouteParameterNames?.Contains("{{endpointParameter.Name}}", StringComparer.OrdinalIgnoreCase) != true every single request for each potential route parameter for performance reasons anyway. We should be caching the result of this during GetGroupedEndpoints. This is more important than improving the compile-time analysis because the runtime check can always work.

[captainsafia]

We shouldn't be checking options?.RouteParameterNames?.Contains("{{endpointParameter.Name}}", StringComparer.OrdinalIgnoreCase) != true every single request for each potential route parameter for performance reasons anyway.

Actually, I think this should be doable if we move the check from here to here. This is what uController does anyways (ref) and we've talked about doing it that way before but this detail was missed in the original implementation. I can take a look at fixing this.