Automatically materialize CTEs

[lnkuiper]

This PR adds functionality to inspect query plans before binding, to find out whether CTEs should be materialized. Currently, DuckDB never materializes CTEs. If CTEs are queried multiple times, they are recomputed, which can be very expensive for large complex CTEs.

The heuristic introduced in this PR is pretty simple: if the CTE performs a (grouped) aggregation and is queried more than once, it should be materialized. This heuristic can be improved in a later PR to also materialize when, e.g., the CTE contains a window function.

Pipeline sharing is something that is on our roadmap for the future, which serves a similar purpose while being more generally useful, but this is much more difficult to implement, so that will have to wait.

To make sure query plans do not regress, I've improved CTE statistics in the join order optimizer.

Some performance improvement highlights below.

TPC-H

benchmark/tpch/sf1/q15.benchmark
Old timing: 0.046487
New timing: 0.024154

TPC-DS

benchmark/tpcds/sf1/q23.benchmark
Old timing: 0.655913
New timing: 0.288761

benchmark/tpcds/sf1/q24.benchmark
Old timing: 0.053736
New timing: 0.031949

benchmark/tpcds/sf1/q36.benchmark
Old timing: 0.141676
New timing: 0.061156

benchmark/tpcds/sf1/q57.benchmark
Old timing: 0.173906
New timing: 0.089459

benchmark/tpcds/sf1/q59.benchmark
Old timing: 0.187678
New timing: 0.097933

benchmark/tpcds/sf1/q64.benchmark
Old timing: 0.240837
New timing: 0.158492

[kryonix]

Hi @lnkuiper cool idea! I've briefly discussed a similar (yet non existing) PR with @Mytherin a while back.

I just glimpsed over the code, so not sure if this is actually an issue currently. But I think this optimization should not be applied when a CTE explicitly requests to be NOT MATERIALIZED, aka. when CTEMaterialize::CTE_MATERIALIZE_NEVER is set.

[Tmonster]

LGTM w.r.t. the join order optimizer. Had a couple of comments about some of the other logic

Also don't quite understand the reference counting stuff, but I think that's just to get a count of the CTEs in a query plan right?

[lnkuiper]

I've also added statistics to LOGICAL_DELIM_GET in the join order optimizer, so we can now reorder join plans with delim gets in them. This slightly improves TPC-H Q2.

EDIT: I've also implemented the feedback by Tom/Denis - thanks a lot!

[lnkuiper]

I've added benchmark/tpch/cte/auto_cte_materialization.benchmark, which is 1.5-2x faster compared to feature.

[Mytherin]

Thanks! LGTM - could you just solve the merge conflict?

[Mytherin]

Thanks!