refactor: consolidate extension planners

[roeap]

Description

We currently create a dedicated session with a dedicated planner in some operations to collect metrics. This creates a situation where - even if we pass a session - we need to recreate the session on the fly, potentially replacing an external planner and thus potentially loosing support for UDFs or other custom nodes.

This PR consolidates the various extension planner we currently have into a single planner to eventually make it easy for us to centralise session creation or allow others to extend their own planner with the delta extension planners.

cc @abhi-airspace-intelligence

Related Issue(s)

part-of: #3799

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.07%. Comparing base (fb73c6f) to head (a776a97).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3804      +/-   ##
==========================================
+ Coverage   76.05%   76.07%   +0.02%     
==========================================
  Files         145      145              
  Lines       45274    45313      +39     
  Branches    45274    45313      +39     
==========================================
+ Hits        34433    34472      +39     
  Misses       9150     9150              
  Partials     1691     1691              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ion-elgreco]

Correct me if I am wrong, but adding all extensions planner together will cause the plan become messy and do multiple metric counts

[roeap]

Correct me if I am wrong, but adding all extensions planner together will cause the plan become messy and do multiple metric counts

The individual planners, while all downcasting to the same MetricObserver node, also match on unqiue IDs on the node for their respective metrics, as long as these don't overlap, only one planner should ever return a plan..

In case there are duplicate IDs we would potentially match wrong depending on the first planner that signifies it can plan the extension node (returning Some(...)). However we do always plan a node at most once .

[ion-elgreco]

Correct me if I am wrong, but adding all extensions planner together will cause the plan become messy and do multiple metric counts

The individual planners, while all downcasting to the same MetricObserver node, also match on unqiue IDs on the node for their respective metrics, as long as these don't overlap, only one planner should ever return a plan..

In case there are duplicate IDs we would potentially match wrong depending on the first planner that signifies it can plan the extension node (returning Some(...)). However we do always plan a node at most once .

Yeah, I thought our IDs werent unique but it's been a while that I've touched these extension planners

[roeap]

it's been a while that I've touched these extension planners

same 😆

In a post kernelized world, I do believe we'll see much more of the likes though ...