This version of ORCA adds missing Xforms that generate Indexed Nested
Loop Join

Signed-off-by: NSambitesh Dash <sdash@pivotal.io>

This reverts commit 45161b0c.

While Bumping ORCA version in commit d8bb2aeb incorrectly updated the
binary from `bin_orca_centos5_release.tar.gz` to
`bin_orca_centos6_release.tar.gz`. Reverting back binary name to
`bin_orca_centos5_release.tar.gz`

Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

Test added for ORCA version v2.55.4
Signed-off-by: NHaisheng Yuan <hyuan@pivotal.io>

Signed-off-by: NBhuvnesh Chaudhary <bchaudhary@pivotal.io>

Older platforms are behind in certificates with the recent change in
upstream github for the allowable TLS versions when clients connect.

Signed-off-by: NJesse Zhang <sbjesse@gmail.com>

Prior to this commit, Orca returned wrong results for queries with left
outer joins containing predicates with `IS DISTINCT FROM`. This has been
fixed as part of ORCA v2.54.4.These are the associated tests.
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

The existing memory accounting test for OOM was not able to exceed the
OOM bound due to the plan generated by ORCA v2.53.11. Prior to that the
it would hit the OOM limit.  This commit updates the
test query to exceed OOM with the latest version of ORCA and also bump
the version to 2.53.11.
Signed-off-by: NAbhijit Subramanya <asubramanya@pivotal.io>

This commit brings in ORCA changes that ensure that a Materialize node is not
added under a Filter when its child contains outer references.  Otherwise, the
subplan is not rescanned (because it is under a Material), producing wrong
results. A rescan is necessary for it evaluates the subplan for each of the
outer referenced values.

For example:

```
SELECT * FROM A,B WHERE EXISTS (
  SELECT * FROM E WHERE E.j = A.j and B.i NOT IN (
    SELECT E.i FROM E WHERE E.i != 10));
```

For the above query ORCA produces a plan with two nested subplans:

```
Result
  Filter: (SubPlan 2)
  ->  Gather Motion 3:1
        ->  Nested Loop
              Join Filter: true
              ->  Broadcast Motion 3:3
                    ->  Table Scan on a
              ->  Table Scan on b
  SubPlan 2
    ->  Result
          Filter: public.c.j = $0
          ->  Materialize
                ->  Result
                      Filter: (SubPlan 1)
                      ->  Materialize
                            ->  Gather Motion 3:1
                                  ->  Table Scan on c
                      SubPlan 1
                        ->  Materialize
                              ->  Gather Motion 3:1
                                    ->  Table Scan on c
                                          Filter: i <> 10
```

The Materialize node (on top of Filter with Subplan 1) has cdb_strict = true.
The cdb_strict semantics dictate that when the Materialize is rescanned,
instead of destroying its tuplestore, it resets the accessor pointer to the
beginning and the subtree is NOT rescanned.
So the entries from the first scan are returned for all future calls; i.e. the
results depend on the first row output by the cross join. This causes wrong and
non-deterministic results.

Also, this commit reinstates this test in qp_correlated_query.sql. It also
fixes another wrong result caused by the same issue. Note that the changes in
rangefuncs_optimizer.out are because ORCA now no longer falls back for those
queries. Instead it produces a plan which is executed on master (instead of the
segments as was done by planner) which changes the error messages.

Also bump ORCA version to 2.53.8.
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

Test files are also updated in this commit as now we don't generate
cross join alternative if an input join was present.

cross join contains CScalarConst(1) as the join condition. if the
input expression is as below with cross join at top level between
CLogicalInnerJoin and CLogicalGet "t3"

+--CLogicalInnerJoin
   |--CLogicalInnerJoin
   |  |--CLogicalGet "t1"
   |  |--CLogicalGet "t2"
   |  +--CScalarCmp (=)
   |     |--CScalarIdent "a" (0)
   |     +--CScalarIdent "b" (9)
   |--CLogicalGet "t3"
   +--CScalarConst (1)
for the above expression (lower) predicate generated for the cross join
between t1 and t3 will be: CScalarConst (1) In only such cases, donot
generate such alternative with the lower join as cross join example:

+--CLogicalInnerJoin
   |--CLogicalInnerJoin
   |  |--CLogicalGet "t1"
   |  |--CLogicalGet "t3"
   |  +--CScalarConst (1)
   |--CLogicalGet "t2"
   +--CScalarCmp (=)
      |--CScalarIdent "a" (0)
      +--CScalarIdent "b" (9)
Signed-off-by: NShreedhar Hardikar <shardikar@pivotal.io>