Having $lookup and $graphLookup stages execute as a Pipeline within a Pipeline will make the execution plan for the aggregation pipeline more explicit. The parsed Pipeline instances will use a copy of the same CollatorInterface so that the $lookup and $graphLookup stages compare string values according to the collation of the collection the "aggregate" command was run on.

Work on this ticket will also change how PlanExecutor instances for aggregation queries are registered, in particular the PlanExecutor underlying DocumentSourceCursor. Currently the DocumentSourceCursor and the PipelineProxyStage classes both reference the underlying PlanExecutor in order to faciliate invalidation notifications for catalog operations such as collection and index drops. We can change the PlanExecutor underlying the DocumentSourceCursor to be registered on the CursorManager of the collection the cursor is on. This will simplify the membrane between the query and aggregation subsystems and will also address the segmentation fault reported in SERVER-24386.