[release/8.0-staging] Handle .NET 10 MemoryExtensions.Contains overload with comparer

[roji]

Fixes #37176 for EF 8.0 (see #37183 for 8.0 fix)

Description

C# 14 first-class spans causes MemoryExtensions.Contains instead of Enumerable.Contains to be resolved, forcing LINQ providers to identify the former in additional to the latter. In addition, .NET 10 introduced a 3-parameter overload to MemoryExtensions.Contains which accepts a comparer, that gets resolved in some situations. While we already backported support for MemoryExtensions.Contains to EF Core 8 and 9, to allow these versions to work with C# 14, we didn't backport a separate change to also support the new .NET 10 overload.

Customer impact

Customers upgrading to .NET 10 but staying on EF 8 or 9 start experiencing failures in some LINQ queries that use Contains. The common case is Contains over an enum array:

_ = await context.Blogs
    .Where(b => new SomeEnum[] { SomeEnum.One, SomeEnum.Too }.Contains(b.SomeEnum))
    .ToListAsync();

Customers upgrading to EF 10 are not affected.

How found

Multiple customers reported on 9.0

Regression

Partial: occurs only when upgrading to .NET 10 but keeping older EF 8 or 9.

Testing

Tested manually, as we don't have automated testing for .NET 10 on older EF versions.

Risk

Very low, targeted change that's very low-risk, and already well-tested in EF 10. Quirk added.

[roji]

/cc @artl93 for initial servicing approval.

[artl93]

Approved for me.

How often do we see regressions like this across versions of .NET?

[artl93]

With the changes needed, should we be running a full test pass on 9.0 and 8.0 - like mock it up in a PR?

[roji]

How often do we see regressions like this across versions of .NET?

Very rarely... There's an inherent increased brittleness with metaprogramming techniques (LINQ providers, Roslyn analyzers/source generators) which operate on representations of user code: any change in overload resolution or similar change in the code representation can trigger a failure. But we almost never see actual such breaks across .NET versions.

With the changes needed, should we be running a full test pass on 9.0 and 8.0 - like mock it up in a PR?

Yeah, that's a good idea - though it seems like it's a bit complicated/non-trivial to have our CI do EF8/9 with .NET 10 (see #37186). I ran some relevant testing locally and will also do the entire SQLite/SQL Server test suites.

[ChrisJollyAU]

Looks good to me

[AndriySvyryd]

Can't you just reuse the above one? Seems like overkill to add a switch for each method

[roji]

Well technically these are two separate changes... this new one only fixes additional recognition for MemoryExtensions.Contains, and in theory could be problematic, causing users to need to roll back without also rolling back the general MemoryExtensions.Contains support.

I tend not to worry too much about quirks (they're in servicing branches only), but if you really prefer it I'll remove the new switch and keep only the existing one for MemoryExtensions.Contains.