ESQL: Add boolean support to Max and Min aggs

[ivancea]

• Added support for Booleans on Max and Min
• Added some helper methods to BitArray (set(index, value) and fill(from, to, value)). This way, the container is more similar to other BigArrays, and it's easier to work with

Part of #110346, as Max and Min are dependencies of Top.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[elasticsearchmachine]

Hi @ivancea, I've created a changelog YAML for you.

[astefan]

These tests are too simple and basic.
Please, add more csv tests that use more complex queries, to also cover complexities associated with plan optimizations. One example:
from employees | eval x = salary is not null | where emp_no > 10050 | stats min(salary is not null), max(x), count(*) by gender

[astefan]

This test and from employees | stats s = min(still_hired) can be a single one, no need to run two queries that do max and min separately.

The same goes for the next pair of queries.

[astefan]

The tests are better, but it can be even better.
When I suggested one query, I was hoping you can come up with more queries in the same idea.

For example: from employees | eval x = salary is not null | where emp_no > 10050 | stats min_salary = min(salary is not null), max_salary = max(x), max_case = max(case(languages > 2, true, false)) by languages which uses the case function.

In employees.csv we have a multi-value boolean field - is_rehired - you can use that and combine it with mv_* functions and feed the result back to min and max (max(mv_min(is_rehired))) with variations.

[ivancea]

@astefan Changes made, and merged with main for new tests:

1. In another PR, aggregation tests were merged for Max and Min. So I included there the boolean cases. It should currently cover an interesting set of cases, and potentially, it would cover much more (grouping for example isn't ready yet, but should be soon).
2. Added some extra CSV cases you commented in the same query.
   I understand that the initial test I did was clearly not enough. But I would stop here for this. Specially with the new non-CSV tests. We could be thinking in new cases for hours otherwise.
   If we want to test a known bunch of cases for functions using the full planner like we do here, I would consider either adding them to the "abstract function test cases", or adding another suite somewhere. Maybe even a list of "you should test this" for CSV function tests in docs we can refer to?
3. About mixing min and max tests, I mixed each function cases in one, instead of mixing the functions. I did this because existing cases do it this way, and to keep different function tests separated. I could mix all "MaxOf" into a single one as I did in Top, but I would avoid doing it unless required (?)

[astefan]

Specially with the new non-CSV tests.

I regard the tests in AbstractFunctionTestCase or AbstractAggregationTestCase and those in csv-spec as completely different and complementary. The former tests the basic functionality of a function, the latter tests the same but in more complex ways that highlight the analyzer, the optimizer, the local optimizer plus nested calls between AggregatorFunctionSuppliers and ExpressionEvaluator.

I understand that the initial test I did was clearly not enough.
...
We could be thinking in new cases for hours otherwise

When adding support to functions (any type - aggregation, scalar, predicates) there should be a human reasonable amount of time spent coming up with some (not all) more complex queries that highlight the new functionality in the form of csv-spec tests. We do have a good coverage and you could take inspiration from other queries we came up with over time.

[astefan]

LGTM

[ivancea]

@elasticmachine update branch

[ivancea]

@elasticmachine update branch