Planner to move to Operator model

[systay]

Internal Refactoring

Since forever, we have had the logicalPlan interface that is used during planning. This served us well on the V3 planner.
In the gen4 work, we introduced the Operator interface that we use when doing the join ordering and route merging.

Once that is done, we transform the operator tree to a logical plan tree to do the grouping/order by/limit planning.

Unfortunately, this means that in some situations we cannot decide early on if we can merge a route with another or not. For example when using derived tables and UNION, if the inner queries are using aggregation, we can't make a good decision during join ordering, and later when we do the aggregation planning, it's too late to merge the routes, because we are by then on logical plans instead.

What I want to do is:

• Make it possible to mix logical and physical operators in the same tree. This will allow us to transform the tree piece by piece, instead of being forced to do everything at once.
• Move a lot of the operator tree traversal to outside the operators. Today a lot of the code on the operators is concerned with sending on calls to the inputs.
• Add column and offset handling to the operators
• Planning projections [gen4 planner] Better handling of projections in operators #12790
• - ordering Gen4 Operator Refactoring: ORDER BY & Debugging Enhancements #12954
• - distinct Handle DISTINCT with the new operators #13201
• - limit Add limit planning to operators #12927
• - aggregation [Gen4] Aggregation and Grouping on Operators #12994
• - HAVING vtgate planner: HAVING in the new operator horizon planner #13289
• - Distinct aggregations (sum(distinct col)))
• Derived tables Derived tables in the new horizon planner #13361
• Subqueries Move subqueries to use the operator model #13750
• UNION Move UNION planning to the operators #13450
• Make it possible to produce 'engine.Primitive' structs straight from the operator tree without first having to transform them to logicalPlan
  Hopefully the refactoring should make the code easier to work with and understand as well.

[harshit-gangal]

Closing this as new operator model is used to plan all the queries.
transform to engine primitive is very lean now.