ADBDEV-3098-2: ORCA produces bogus plan for queries with CTE during handling distribution for Sequence children

[RekGRpth]

With some conditions ORCA generates Redistribute Motion from all segments to one segment which can not executed because inconsistency CTE producers and consumers.
For example, create tables

CREATE TABLE a (a bigint, b bigint) DISTRIBUTED BY (a);
CREATE TABLE b (a bigint, b bigint, c bigint, d bigint) DISTRIBUTED BY (a) PARTITION BY LIST(b) (PARTITION a VALUES(0));
CREATE TABLE c (a bigint, b bigserial, c varchar(255)) DISTRIBUTED REPLICATED;

and run

EXPLAIN (ANALYZE off, COSTS off, VERBOSE off)
WITH d AS (
    SELECT b FROM a GROUP BY b
), e AS (
    SELECT b.d FROM b JOIN d f ON f.b = b.c JOIN d g ON g.b = b.c
) SELECT * FROM e JOIN c ON c.a = e.d;

that gives bogus plan

                                                QUERY PLAN                                                 

-----------------------------------------------------------------------------------------------------------
 Gather Motion 1:1  (slice4; segments: 1)
   ->  Sequence
         ->  Shared Scan (share slice:id 4:0)
               ->  Materialize
                     ->  GroupAggregate
                           Group Key: a.b
                           ->  Sort
                                 Sort Key: a.b
                                 ->  Redistribute Motion 3:1  (slice3; segments: 3)
                                       Hash Key: a.b
                                       ->  Seq Scan on a
         ->  Hash Join
               Hash Cond: (c.a = b.d)
               ->  Seq Scan on c
               ->  Hash
                     ->  Broadcast Motion 3:1  (slice2; segments: 3)
                           ->  Hash Join
                                 Hash Cond: (share0_ref3.b = b.c)
                                 ->  Shared Scan (share slice:id 2:0)
                                 ->  Hash
                                       ->  Hash Join
                                             Hash Cond: (b.c = share0_ref2.b)
                                             ->  Redistribute Motion 3:3  (slice1; segments: 3)
                                                   Hash Key: b.c
                                                   ->  Sequence
                                                         ->  Partition Selector for b (dynamic scan id: 1)
                                                               Partitions selected: 1 (out of 1)
                                                         ->  Dynamic Seq Scan on b (dynamic scan id: 1)
                                             ->  Hash
                                                   ->  Shared Scan (share slice:id 2:0)
 Optimizer: Pivotal Optimizer (GPORCA)
(31 rows)

In this plan Shared Scan (share slice:id 4:0) is CTE producer that is executed only on one segment because Redistribute Motion 3:1 (slice3; segments: 3), but CTE consumers (Shared Scan (share slice:id 2:0)) are executed on all 3 segments and then query hangs.

Solution is changing Redistribute Motion to from all segments to all segments which is done by changing gang type of parent slice from singleton reader to primary reader and refill gang info of parent slice. It is gives right plan

                                                QUERY PLAN                                                 

-----------------------------------------------------------------------------------------------------------
 Gather Motion 3:1  (slice4; segments: 3)
   ->  Sequence
         ->  Shared Scan (share slice:id 4:0)
               ->  Materialize
                     ->  GroupAggregate
                           Group Key: a.b
                           ->  Sort
                                 Sort Key: a.b
                                 ->  Redistribute Motion 3:3  (slice3; segments: 3)
                                       Hash Key: a.b
                                       ->  Seq Scan on a
         ->  Hash Join
               Hash Cond: (c.a = b.d)
               ->  Seq Scan on c
               ->  Hash
                     ->  Broadcast Motion 3:3  (slice2; segments: 3)
                           ->  Hash Join
                                 Hash Cond: (share0_ref3.b = b.c)
                                 ->  Shared Scan (share slice:id 2:0)
                                 ->  Hash
                                       ->  Hash Join
                                             Hash Cond: (b.c = share0_ref2.b)
                                             ->  Redistribute Motion 3:3  (slice1; segments: 3)
                                                   Hash Key: b.c
                                                   ->  Sequence
                                                         ->  Partition Selector for b (dynamic scan id: 1)
                                                               Partitions selected: 1 (out of 1)
                                                         ->  Dynamic Seq Scan on b (dynamic scan id: 1)
                                             ->  Hash
                                                   ->  Shared Scan (share slice:id 2:0)
 Optimizer: Pivotal Optimizer (GPORCA)
(31 rows)

Upstream master (gpdb 7) also is affected by this problem, but with other error

FATAL:  Unexpected internal error (assert.c:44)
DETAIL:  FailedAssertion("!(pMotion->numHashSegments < motion_recv)", File: "explain.c", Line: 2513)
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.