Add EF.Parameter to force parameterization in query

[roji]

In F#, closure parameters are integrated into the query expression tree as constant nodes - see dotnet/fsharp#12841 for the full details. This means that by default, all EF queries generate SQL with constants rather than parameters.

A workaround is to use a F# ref, which gets properly parameterized by EF Core:

let i = ref 8
db.Events.Where(fun x -> x.Data = i.Value).ToList();

However, while this works well with local variables, it's problematic for use with function parameters, since the parameter needs to be typed as Ref<T> (it isn't great to require people to change method signatures just so that an EF query inside get properly parameterized). Note that the variable name is also lost, so the SQL contains @__Value_0.

We could introduced an EF.Param() mechanism, which is identified by EF Core and forces parameterization. The same mechanism could be used in C# to force parameterization for better perf when two queries use different constants, without needing to extract a variable:

var query1 = await ctx.Blogs.Where(b => b.Name == EF.Param("foo")).ToListAsync();
...
var query2 = await ctx.Blogs.Where(b => b.Name == EF.Param("bar")).ToListAsync();

EF.Param could optionally also accept the SQL parameter name, to produce more readable SQL queries.

/cc @dsyme @NinoFloris

[roji]

Additional advantage of this: for users building an expression tree dynamically, it would make it considerably easier to integrate a value as a parameter into the expression tree.

[smitpatel]

Restriction on the API would be that the argument to the method must be a constant value. (this also works in dynamic tree building scenario where user generally creates ConstantExpression).

We would also evaluate anything which composes over as long as it is evaluate-able using normal rules of maximum possible evaluation.

e.g. EF.Param("foo").Length would get fully evaluated and generated parameter of value 3 in expression tree.

[pinkfloydx33]

This would be really useful for us. We have a bunch of query building methods that dynamically craft an expression tree. We were ending up with constant values plugged directly into the query because we were using Expression.Constant. As a workaround I use the following helper method to force a closure over the value(s) passed into our builders:

public static Expression CloseOver<T>(T constant)
   => ((Expression<Func<T>>)(() => constant)).Body;

Which we then use in lieu of Expression.Constant when dealing with various input values. So far this seems to work w/r/t parametrization, however we end up with parameters all named constant_{n} (the name of the parameter/display class field) which is a bit unfortunate. I'm also not sure if it's guaranteed to work or not and it feels a tad bit hacky.

It'd be great if we had some built-in method we could Expression.Call instead that would properly recognize this and turn the inputs into parameters named accordingly.

[roji]

@pinkfloydx33 your workaround above is fine and guaranteed to work - it just reproduces the normal non-dynamic thing that happens when a closure variable is captured. But it's true that the parameter name isn't pretty.

[roji]

Do this together with #31552, which does the opposite, adding EF.Constant to force constantization.