[AOT] Add expression free request filter pipeline for RequestDelegate

[JamesNK]

Fixes #46014

The goal here is to remove System.Linq.Expressions dependency from mapping RequestDelegate endpoints (i.e. basic, non-minimal API endpoints). This allows apps that map basic endpoints to avoid warnings from expressions, and reduce publish size by trimming away expressions assembly.

Changes:

• Add InferMetadataFunc and CreateHandlerRequestDelegateFunc to RouteEntry.
• RequestDelegate now registers its own func for building request filter factory pipeline. It doesn't use System.Linq.Expressions.
• There is some messiness in sharing code because mapping RequestDelegate routes lives in Microsoft.AspNetCore.Routing. All of RequestDelegateFactory lives in Microsoft.AspNetCore.Http.Extensions. I tried to share code using source file linking, but a cleaner solution would be to add a public RequestDelegateFactory.Create(RequestDelegate, ...) overload that Microsoft.AspNetCore.Routing can call. Thoughts? Edit: API proposal - [API] RequestDelegateFactory.Create RequestDelegate overload #46024

@halter73 @davidfowl This is a start to the changes you discussed making. The next step after this PR is to make public API to configure InferMetadataFunc and CreateHandlerRequestDelegateFunc. Then source generated code can inject its own logic.

[JamesNK]

Numbers!

• Before: 17316 KB
• After: (referencing EmptyHttpResult): 16052 KB
• After (not referencing EmptyHttpResult): 15316 KB

Test app:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", (HttpContext c) => Task.CompletedTask);
app.Run();

Good news is System.Linq.Expressions warnings are gone, and there is precisely a 2 MB reduction in published Windows AOT size 🚀

There are two after results. I noticed that the hack to get the empty HTTP result brought in a lot of Microsoft.AspNet.Core.Http.Results. The difference between it being used or not is a large publish size increase and a lot of warnings from the results assembly. I'm not sure why Type.GetType("Microsoft.AspNetCore.Http.HttpResults.EmptyHttpResult, Microsoft.AspNetCore.Http.Results") appears to bring all result types from that assembly 🤷‍♂️

A simple fix could be to move EmptyHttpResult to Microsoft.AspNetCore.Http.Abstractions and type forward from Http.Results. Then Microsoft.AspNetCore.Routing an easily reference it. IMO it is common for an "empty" result to be part of the abstraction.

[davidfowl]

I think we should move empty result down as well

[DamianEdwards]

@JamesNK typo in the numbers? Should those have a decimal point in them somewhere or just be bytes instead if MB?

[JamesNK]

Ah, yeah, KB

[eerhardt]

This looks good to me, but I'm definitely no expert in this area.

[eerhardt]

How does this work with source generation, if we always get the JsonTypeInfo for object?

[davidfowl]

https://github.com/dotnet/aspnetcore/pull/46020/files#diff-8e7a4b7b1b9fd8d37f7052f449953179d0e66edb4b10ea693a7a0dd18506fec1R51-R52

[eerhardt]

This is weird, but OK I guess.

[davidfowl]

Very weird.