CSHARP-3222: Add LINQ support for median and percentile accumulators/window functions

[adelinowona]

This PR introduces the capability to calculate the median and percentile of numeric values in the MongoDB aggregation pipeline for $group and $setWindowFields stages.

[rstam]

Initial quick review. Will review more thoroughly after next commit.

[rstam]

Normally we do if (method.IsOneOf(__medianMethods)).

Do we want to do it differently here?

[adelinowona]

I noticed that pattern but I just felt that would be too much boilerplate kind of code and there's an easier way to do it. Plus I noticed the StandardDeviationMethodsToAggregationExpressionTranslator follows a similar pattern already.

[rstam]

There is some boilerplate in setting up the __medianMethods static field.

There isn't any boilerplate in the if statement. It's roughly the same.

One advantage of using __medianMethods is that it is VERY precise. There is no danger of false hits like there is with the IsMedianMethod approach.

Plus I noticed the StandardDeviationMethodsToAggregationExpressionTranslator follows a similar pattern already.

Yes. That's older code that predates the newer practice of being more precise.

[rstam]

Changes requested

[rstam]

There is some boilerplate in setting up the __medianMethods static field.

There isn't any boilerplate in the if statement. It's roughly the same.

One advantage of using __medianMethods is that it is VERY precise. There is no danger of false hits like there is with the IsMedianMethod approach.

Plus I noticed the StandardDeviationMethodsToAggregationExpressionTranslator follows a similar pattern already.

Yes. That's older code that predates the newer practice of being more precise.

[rstam]

This is clever but I don't like the idea of a Dictionary<string, AstExpression>. A class that can represent anything in this way is not easy to work with.

I would prefer you just create two new classes AstMedianAccumulatorExpression and AstPercentileAccumulatorExpression.

That would mirror AstMedianExpression and AstPercentileExpression.

It would also avoid the messiness in the VisitComplexAccumulatorExpression method. Instead we could just have two simple methods VisitMedianAccumulatorExpression and VisitPercentileAccumulatorExpression.

The whole point of the Ast classes is to have type-safe representations of MQL, and the use of a Dictionary<string, AstExpression> throws type-safety out the window.

[adelinowona]

That's fair. I'll revert this then

[rstam]

I'm still concerned that the return type is double instead of decimal.

Same below.

[adelinowona]

discussed on slack. The Server team currently has $median returning doubles regardless of input type but there is a ticket for improving accuracy in the future to return the correct types. So I'll change the return type here to decimal.

[rstam]

Enumerable.Average(IEnumerable<float>) returns float.

Should we also?

[rstam]

Should we return decimal[]

[rstam]

Should the percentiles be decimal also to match?

[rstam]

Should we return float[]?

SHould the percentiles web IEnumerable<flost> to match?

[rstam]

Should we return decimal?

[rstam]

Very close to done!

[rstam]

LGTM

[sanych-sun]

LGTM