Use interceptors to redirect the query to precompiled code

[AndriySvyryd]

See https://github.com/dotnet/roslyn/blob/main/docs/features/interceptors.md

• Identify and properly intercept all terminating operators
  • ExecuteUpdate/Delete
• Use ISyntaxGenerator in LinqToCSharpSyntaxGenerator, to avoid e.g. parentheses/operator precedence issues.

Specific query types to keep in mind and test:

• SQL queries
• Split query
• GroupBy final operator (materializer work)
• Shared-type entity types (in various places where we do entity lookups)
• Improve tests to assert on results, possibly on SQL.

[roji]

We had a phase where we discussed this... Back then I thought it wouldn't be possible, but I'm not sure any more.

The main problem here is that we need to extract parameters from lambdas in the various LINQ operators that make up the query:

x = context.Blogs.Where(b => b.Name = foo).ToList();

So Where would have to be replaced with something that actually goes and extracts the parameter value, populating it into a QueryContext that flows from the root. It's certainly not trivial stuff, but may be doable - and it would allow us to get compiled query perf (or very near it) with regular queries in code.

Definitely something we should think about.

[roji]

Note: there's one specific query type which interceptors won't support - foreach over a DbSet property:

foreach (var blog in context.Blogs)
{
    ...
}

The workaround here would be for the user to add AsEnumerable(), which we'd then intercept. A precompilation analyzer could provide a codefix (#32727).