Fix allocations of an unreachable fallback code

[fiseni]

While working on our benchmarks, I faced a peculiar issue. Some of the unreachable code in our validators and evaluators is allocating memory. It seems an enumerator is created even though we never reach that section. Here is an example.

public bool IsValid<T>(T entity, ISpecification<T> specification)
{
    if (specification is Specification<T> spec)
    {
        if (spec.OneOrManySearchExpressions.IsEmpty) return true;

        if (spec.OneOrManySearchExpressions.SingleOrDefault is { } searchExpression)
        {
            return searchExpression.SelectorFunc(entity)?.Like(searchExpression.SearchTerm) ?? false;
        }

        // The search expressions are already sorted by SearchGroup.
        return IsValid(entity, spec.OneOrManySearchExpressions.List);
    }

    // We'll never reach this point for our specifications.
    // This is just to cover the case where users have custom ISpecification<T> implementation but use our validator.
    // We'll fall back to LINQ for this case.

    foreach (var searchGroup in specification.SearchCriterias.GroupBy(x => x.SearchGroup))
    {
        if (!searchGroup.Any(c => c.SelectorFunc(entity)?.Like(c.SearchTerm) ?? false))
            return false;
    }

    return true;
}

If we move the fallback code to a local function, allocations go away. So, I assume some compiler (or even runtime) optimizations mess up our assumptions. We should apply this fix wherever applicable.

PS. We'll categorize this as a bug. It's not a bug per se, the behavior remains correct, there are just unnecessary allocations.

[fiseni]

It turns out the extra allocation comes from the closure in the "unreachable" code; we're capturing the entity in the lambda for Any. It's a bit counterintuitive; the code that is not executed allocates memory, but the compiler always instantiates the closures (the DisplayClass) at the start of the method. We have to fix these occurrences by introducing a local function for these fallback paths.