Enable `nestloop` in GPDB and for CBDB?

Guc enable_nestloop is default false in GPDB.
(The reason may be that nestloop join in GPDB need broadcast motion with hight cost).
But it will result in different plan with pg for some cases.

case in join.sql

```
explain (verbose)
select unique1, x.*
from tenk1, (select *, random() from f_immutable_int4(1) x) x
where x = unique1;
QUERY PLAN

--------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------
Gather Motion 3:1 (slice1; segments: 3) (cost=0.05..70.94 rows=13 width=16)
Output: tenk1.unique1, (1), (random())
-> Hash Join (cost=0.05..70.77 rows=4 width=16)
Output: tenk1.unique1, (1), (random())
Hash Cond: (tenk1.unique1 = (1))
-> Seq Scan on public.tenk1 (cost=0.00..62.33 rows=3333 width=4)
Output: tenk1.unique1, tenk1.unique2, tenk1.two, tenk1.four, tenk1.ten, tenk1.twenty, tenk1.hundred, tenk1.thousand, tenk1.twothous
and, tenk1.fivethous, tenk1.tenthous, tenk1.odd, tenk1.even, tenk1.stringu1, tenk1.stringu2, tenk1.string4
-> Hash (cost=0.04..0.04 rows=1 width=12)
Output: (1), (random())
-> Redistribute Motion 1:3 (slice2; segments: 1) (cost=0.00..0.04 rows=1 width=12)
Output: (1), (random())
Hash Key: (1)
-> Result (cost=0.00..0.01 rows=1 width=12)
Output: 1, random()
Optimizer: Postgres query optimizer
(15 rows)
```

When enable nestloop is off, it will use hash join and seqscan for table tenk1.

```
set enable_nestloop = on;

explain (verbose)
select unique1, x.*
from tenk1, (select *, random() from f_immutable_int4(1) x) x
where x = unique1;
QUERY PLAN
---------------------------------------------------------------------------------------------------
Gather Motion 3:1 (slice1; segments: 3) (cost=0.16..4.41 rows=13 width=16)
Output: tenk1.unique1, (1), (random())
-> Nested Loop (cost=0.16..4.23 rows=4 width=16)
Output: tenk1.unique1, (1), (random())
-> Redistribute Motion 1:3 (slice2; segments: 1) (cost=0.00..0.04 rows=1 width=12)
Output: (1), (random())
Hash Key: (1)
-> Result (cost=0.00..0.01 rows=1 width=12)
Output: 1, random()
-> Index Only Scan using tenk1_unique1 on public.tenk1 (cost=0.16..4.18 rows=1 width=4)
Output: tenk1.unique1
Index Cond: (tenk1.unique1 = (1))
Optimizer: Postgres query optimizer
Settings: enable_nestloop = 'on'
(14 rows)

```

Start with the join.sql case and reproduce both plans using enable_nestloop off and on for the tenk1 and f_immutable_int4 query. Read the planner handling for this setting and compare GPDB with PostgreSQL and CBDB behavior; done means the intended default and resulting plan behavior are defined and covered by a regression test.

Written by the indexing model from the issue text.