It was quite clearly broken, as it didn't do anything with the new_tle
that it chased up, and the end result was just the same as calling
canonicalize_pathkeys() on the input.

I'm not 100% the code is doing the right thing even with this: If the
pathkey's operator family doesn't match the join clause's operator family,
the output isn't truly ordered the same way. This is not an issue for the
case that I included in the regression test, where the join happens on a
constant, but I can't figure out whether this might be an issue with some
other query.

This code and bug was in 1f4ad703, and it
caused an "operator XXX is not a valid ordering operator" error.

The 'sortop' field in SortClause and GroupClause needs to be an ordering
operator, i.e. the "<" operator, while we use the "=" operator to represent
grouping in other places. Need to be careful to convert between the two
in right places.

Add a few tests for this in the gp_dqa test case. This was reproducible by
the existing queries, when you coerce the planner to choose sort+group
aggregates instead of hash aggregates.