Rewrite the way SubPlans are "parallelized".

The old way was to construct a plan for a correlated subquery was to plan
the subquery as usual, except that Index Scans were not allowed. Then,
after constructing a Plan tree, the post-processing step apply_motion()
added Redistribute motion nodes so that the plan tree was executable on
any node. That was pretty simplistic; disabling Index Scans completely
obviously hurts performance. Also, because the planner didn't take into
account that all base relations are actually redistributed everywhere,
it was not reflected in the cost estimates, and the planner might choose
a sub-optimal plan.

To improve that, change the way that works, so that the Motions are added
earlier in the planning. The planner needs to know which restrictions
(WHERE clauses) refer to the outer query, i.e. which quals are correlated,
and make sure that those quals are always evaluated in the same slice as
the parent query. The outer query cannot pass parameters down through a
Motion node, so the subquery plan must not contain any Motion nodes
between the evaluation of the correlated variable, and the outer plan.
This is enforced by having a new CdbPathLocus type, "OuterQuery". A node
with OuterQuery locus must be evaluated in the outer query. It is mostly
the same as "general", which means that it can be evaluated anywhere, but
with the restriction that it is not OK to redistribute an input that has
OuterQuery locus. Whenever the planner node evaluates a correlated var,
that node must have Upper locus, by adding Motions below that node. This
has similar effect as the old approach, but gives the planner a bit more
flexibility, and the motions are taken into account in cost estimates.

This allows using Index Scans in subplans, but only if the Index Quals
don't contain correlated vars. This still isn't perfect, it would
sometimes be good to for example delay the evaluation of a correlated var
later, above a join node, because that might avoid expensive Redistribute
Motions. Even though this patch doesn't allow such plans yet, it's a step
in the right direction.

This moves the cdbllize() step to run *before* set_plan_references().
Now that we no longer add Motion nodes to an already-constructed plan
tree, we don't need the 'useExecutorVarFormat' stuff in many functions
anymore.

Fixes https://github.com/greenplum-db/gpdb/issues/8648

Reviewed-by: Melanie Plageman <mplageman@pivotal.io>
Reviewed-by: Soumyadeep Chakraborty <sochakraborty@pivotal.io>

Author: hlinnaka

contrib/auto_explain/expected/auto_explain.out

@@ -89,11 +89,8 @@ Aggregate  (cost=10000035148.67..10000035148.68 rows=1 width=8) (actual rows=1 l
                     ->  Seq Scan on auto_explain_test.t1  (cost=0.00..13.01 rows=334 width=0) (actual rows=340 loops=1)
                           Output: t1.a
                     ->  Materialize  (cost=0.00..68.06 rows=1001 width=0) (actual rows=1001 loops=340)
-                          Output: t2.b
                           ->  Broadcast Motion 3:3  (slice1; segments: 3)  (cost=0.00..53.05 rows=1001 width=0) (actual rows=1001 loops=1)
-                                Output: t2.b
                                 ->  Seq Scan on auto_explain_test.t2  (cost=0.00..13.01 rows=334 width=0) (actual rows=340 loops=1)
-                                      Output: t2.b
   (slice0)    Executor memory: 131K bytes.
   (slice1)    Executor memory: 43K bytes avg x 3 workers, 43K bytes max (seg0).
   (slice2)    Executor memory: 216K bytes avg x 3 workers, 216K bytes max (seg0).