MultiPlanner is used outside of CBR, and has appropriate ownership requirements (e.g., it can own solutions, PlannerData, etc.).

This is sensible, and was the state before CBR existed.

Some CBR strategies use MultiPlanner internally. However, this requires CBR to release ownership of assorted structures (primarily the vector of query solutions) to the MultiPlanner.

This causes problems, as CBR may actually still need that state too. This leads to contrivances like:

• Repeated enumeration of solutions, leaving two copies
• "extract" methods to steal back state that had to be surrendered
• Mental overhead to reason about who owns what at a given point

This has lead to a number of safety issues, and repeated "violation of the principle of least surprise", when devs encounter things like a vector of solutions with one entry, but it is a nullptr (and ownership is actually elsewhere).

—

To resolve this, move CBR strategies to drive the MultiPlanStage directly. This allows rankers to occupy the same "position" as MultiPlanner - owning state and driving the stage.

This is also an incremental step to making strategies more composable - strategies which currently use MP and CBR will be much simpler when both can operate over the same state (and can be interleaved without stealing and restoring assorted state).