Resolve the conflicts and add support for top hash aggregate and local s...

...erial agg
OK. This all looks like a good change, ready to go, but now I wonder if there are other cases we are still missing out on a possible top hashed and bottom serial agg combination. There is a comment around line 1433 that hints at this, but it refers to "we just need to fix both aspects of ENG-4096" but that ticket is Resolved and it does not even reference partitioned tables.

The case you are handling here is specifically where we were going to do a seqscan but figured out that we could purposely use an indexscan to allow a serial agg. I think that it was just a silly bug that we did not follow through to create the serial bottom agg -- why else go through the expense of the indexscan?

But I think that there may be other cases. What if we were already going to do an index scan because we have a range filter -- one that happens to select an index that covers (orders by) all the GROUP BY keys (ascending or descending -- does not matter). That should be enough to trigger the bottom agg to be serial with the top agg still needing to be hashed  -- unless the partition key is in the group by and so there is no topagg, only a bottom serial agg. We should try to repro these edge cases and file new tickets if they are real.