Respect size parameter in aggregations (1/3 - refactor)

[trzysiek]

Basically moves SimpleQuery from queryparser package to model. Also starts a small refactor to aggregation_parser, which is the motivation for this change. Before we had 1 function parse_some_aggregation_type. Now I split it into 2: parse and process. I think it simplifies a lot of things + enables making plugins for new aggregations quite easy.

edit2: comments below are obsolete. Changed this PR into refactor, next will follow.

Edit: I think it works 100% fine now, although this issue is generally pretty tricky, and hard to get right, and code is so far pretty ugly, because of a lot of trial and error approaches.
1 test was failing after some small fixes, and I finally managed to make it work at the end. Will check rest of tests tomorrow, but I'm 99% they'll pass.

Generally, plan is to transform (multiple) terms (simple split into buckets, or GROUP BY with limit) (e.g. with LIMITs 2 and 5) into something like this:

SELECT customer_id, toInt64(taxless_total_price / 20) FROM opensearch_dashboards_sample_data_ecommerce
    WHERE customer_id IN 
        (SELECT customer_id FROM opensearch_dashboards_sample_data_ecommerce GROUP BY customer_id ORDER BY customer_id LIMIT 2)
    GROUP BY customer_id, toInt64(taxless_total_price / 20)
	ORDER BY customer_id, toInt64(taxless_total_price / 20)
	LIMIT 5 BY customer_id

First terms uses normal LIMIT N, 2+ terms use LIMIT N BY [previous terms]
You can paste this into our Clickhouse to see that such a query is correct

Old comments:

Before: we didn't add LIMIT x anywhere, so we were displaying all buckets.
After: well, I tried visualizing a lot of charts in OpenSearch and it seems to work everywhere, even this Other bar.

BUT
a) not important, fixed on Tuesday I'm pretty sure the code isn't perfect, as I said I can't break it easily in UI, but with more complex aggregations it probably will not work 100% correctly. The PR code isn't prettiest, maybe some small refactor which is needed anyway will help with that correctness issue.
b) still valid, but not very important, and not very hard Order (by) parameter in query still isn't respected.

I'd leave b) for next PR.

[trzysiek]

simply copied from queryparser package

[jakozaur]

Ok it got moved, not copied.

[trzysiek]

code is the same as before, added only a few checks which were missing.
Moved from big single file to a separate one

[trzysiek]

Rest of those functions will also have finish... name, I think more appropriate, if you don't agree, maybe let's argue in next PR when I change all

[trzysiek]

moved to model

[trzysiek]

it's only used in tests, these prints help when they fail

[jakozaur]

The general comment is that "LIMIT N BY " is an unusual SQL method. Most databases do not support this. Quesma would still need to generate a query for that database without this clause.

[jakozaur]

Ok, I would need walkthrough. I see a lot of refactoring changes which are ok.

Some logic there I don't understand.

[jakozaur]

Ok it got moved, not copied.

[jakozaur]

Don;t get it.

[trzysiek]

Used to be like that before.
.Type keeps what type of aggregation it is, here some filters.
.whereBuilder keeps where clause as string, I combine, so do old_where AND this_filter's_where
.Aggregators = list of aggregation names to be put in response's JSON. We add filter.name where it's kept.
resultAccumulator = result list of all queries we need to send to DB, we add 1 here for each filter