When filesort heap-merges sort chunks into a new file, it enters a
special code path whenever there's only one sort chunk left (it doesn't
care about the priority queue anymore; it just copies the rows).
This code path had a microoptimization to count the number of remaining
rows (which would be different from the number of input rows if there
is a LIMIT baked into the sort), which didn't hold if deduplication were
active, for instance in a DISTINCT. If a row was deduplicated in that
path, the row count would be too high, and when the row was re-merged
in the next phase, we'd read a bogus row.

There's no test case for this, as any trigger must necessarily create
megabytes of very specific test data to get enough chunk merges.

Change-Id: If3f5a7779d4dfb81f6d3c82861a58b2ddda8700b