Wrong results from GROUP BY column removal

I was reloading my memory of the various uniqueness proofs in our
code, in order to pick the UniqueKeys work back up, and I noticed a
thinko in remove_useless_groupby_columns().

/*
* We must insist that the index columns are all defined NOT
* NULL otherwise duplicate NULLs could exist. However, we
* can relax this check when the index is defined with NULLS
* NOT DISTINCT as there can only be 1 NULL row, therefore
* functional dependency on the unique columns is maintained,
* despite the NULL.
*/

This reasoning doesn't hold when the relation is on the nullable side
of an outer join. The rows null-extended by the join have NULLs in
the indexed columns too, so once the other columns are removed from
the GROUP BY, they end up in the same group as the relation's one real
NULL row, even though they differ from it in those columns. It's not
hard to come up with a query that gives wrong results because of this.

create table t1 (a int);
create table t2 (a int, b int not null);
create unique index on t2 (a) nulls not distinct;
insert into t1 values (1), (9);
insert into t2 values (null, 1);

select t2.a, t2.b, count(*) from t1 left join t2 on t1.a = t2.b group
by t2.a, t2.b;
a | b | count
---+---+-------
| 1 | 2
(1 row)

There should be two groups here, (NULL, 1) and (NULL, NULL).

I think we can fix this by not applying the NULLS NOT DISTINCT
relaxation when the relation's GROUP BY Vars can be nulled by an outer
join, which we can tell from their varnullingrels. See attached.

I think this needs to be back-patched to v18.

- Richard