Fixing named query cache misses by adding support for collections in …

[bittola]

Fixing named query cache misses by adding support for collections inconstant expression comparer

fixes #37112

• I've read the guidelines for contributing and seen the walkthrough
• The code builds and tests pass locally (also verified by our automated build checks)
• Tests for the changes have been added (for bug fixes / features)
• Code follows the same patterns and style as existing code in this repo

[bittola]

There are some limitations with this approach. At this point we don't have any information about the intent. In some cases we don't care about the order of elements in the collection, nor we care about the type of the collection. We just care that the elements are the same in no particular order.

With the implementation above we get the cache hit only when the type of the collection and order of the elements is the same.
For example:

var result = context.Entities
    .IgnoreQueryFilters(["ActiveFilter", "NameFilter"])
    .ToList();
_ = context.Entities
    .IgnoreQueryFilters(["ActiveFilter", "NameFilter"])
    .ToList();

However, the following won't work:

var result = context.Entities
    .IgnoreQueryFilters(["ActiveFilter", "NameFilter"])
    .ToList();
_ = context.Entities
    .IgnoreQueryFilters(["NameFilter", "ActiveFilter"])
    .ToList();

it will work with sorted collection for example

var result = context.Entities
    .IgnoreQueryFilters(new SortedSet<string> { "ActiveFilter", "NameFilter" })
    .ToList();
_ = context.Entities
    .IgnoreQueryFilters(new SortedSet<string> { "NameFilter", "ActiveFilter" })
    .ToList();

The question is how to pass that information to the comparer that we care or not about the order. We only have a type information. If we are OK with this limitation, then fine

[bittola]

Another thing we may need to consider is to limit this to more specific interface like ICollection or so