Blocking plans may reach a memory limit during execution, and abort with an error.

The cost model should be able to avoid such plans by computing the memory cost, and preferring streamed plans when memory needed by a plan doesn't fit within the memory limit.

Multi-planner rules out such plans and creates a "backup" plan if it reaches the memory limit during multi-planning, but this seems a very limited approach because it can't take into account the whole memory needed by a plan.

For reference, there is one unit test that recreates this situation in 

https://github.com/10gen/mongo/blob/7131cb115b34d654625d25d1e53d26133990d3a3/src/mongo/dbtests/plan_ranking.cpp#L226

And a few more tests in the same test file create a similar situation with a backup plan.

CBR should implement its own way to handle OOM situations in blocking plans.