Inconsistency in reduce input record counters between the stable and evolving APIs

In the stable (mapred) API execution, if the values iterator is skipped by a user, the records underneath it aren't counted in the "Reduce input records" counter as the key progresses to the next unique one. In the evolving API (mapreduce) API execution, if the values iterator is skipped by a user, the records underneath it is still counted as the key progresses to the next unique one.

This behavior comes to me as a faulty one in the old API. A "Reduce input records" counter must always define all the records that have been passed into a reducer (cause they are read regardless of skipping), and both API's record counting despite user applications must be consistent.

I'll post a test case illustrating this shortly.