Simplify cohort filters

[macobo]

Changes

Follow-up to #6221

This PR starts "simplifying" cohort filters. The idea is to have the business logic bits happen before we do query building, which allows to do better optimizations, e.g. avoid unneeded subqueries.

The cases that got simplified are:

• Cohort has person property filters - we add these filters to the filter object
• Cohort would query precalculated/static cohort tables - we add that query.
  • There was one sessions query which did not join distinct_ids -> needed to take special care here.

Not everything is simplified yet. There's 3 cases which I'd love to tackle in a follow-up:

• When the cohort does not exist anymore
• Cohort has action filter (e.g. has done X in timerange)
• Cohort has multiple filters combined with an OR

Once all of these are done we can "delete" a lot of special-case query building logic :)

One benchmark got slower. This is because a large column got communicated between threads which was previously used only in a subquery. This will be improved again by #5850 which this is a prerequisite for.

How did you test this code?

See test coverage. I verified all of insights + sessions work with the new cohort cases.

[github-actions]

ClickHouse query benchmark results from GitHub Actions

Lower numbers are good, higher numbers are bad. A ratio less than 1
means a speed up and greater than 1 means a slowdown. Green lines
beginning with + are slowdowns (the PR is slower then master or
master is slower than the previous release). Red lines beginning
with - are speedups. Blank means no changes.

Significantly changed benchmark results (PR vs master)

       before           after         ratio
     [04045ff4]       [7203ca4e]
+  7617.0±2.2e+02  11564.0±2.7e+02     1.52  benchmarks.QuerySuite.track_trends_filter_by_cohort
-       7158.5±59   5905.5±1.4e+02     0.82  benchmarks.QuerySuite.track_trends_filter_by_cohort_materialized

Click to view full benchmark results

All benchmarks:

     before           after         ratio
   [04045ff4]       [7203ca4e]
19180.5±1.4e+03  20986.0±1.2e+03     1.09  benchmarks.QuerySuite.track_trends_event_property_filter
 4276.0±4.3e+02        4184.5±88     0.98  benchmarks.QuerySuite.track_trends_event_property_filter_materialized
+  7617.0±2.2e+02  11564.0±2.7e+02     1.52  benchmarks.QuerySuite.track_trends_filter_by_cohort
-       7158.5±59   5905.5±1.4e+02     0.82  benchmarks.QuerySuite.track_trends_filter_by_cohort_materialized
 5592.0±2.6e+02   5416.0±1.3e+02     0.97  benchmarks.QuerySuite.track_trends_filter_by_cohort_precalculated
      2074.0±40        2107.5±22     1.02  benchmarks.QuerySuite.track_trends_no_filter
     11185.5±72       11656.0±88     1.04  benchmarks.QuerySuite.track_trends_person_property_filter
      5879.5±65        6072.0±81     1.03  benchmarks.QuerySuite.track_trends_person_property_filter_materialized

[EDsCODE]

all points I had were covered in the description.

Thought I had while reading through this PR: would be nice to have some sort of full print of queries generated by certain functions. (We've talked about this previously but just thought of it again)

[macobo]

Thought I had while reading through this PR: would be nice to have some sort of full print of queries generated by certain functions. (We've talked about this previously but just thought of it again)

Absolutely. I'm waiting for the dice to fall on the way we'll write queries - if we'll use pytest going forward we can bring in a functioning snapshot library.