Re: Add a test for index_rebuild_count of REPACK (CONCURRENTLY)

My fault: I sent the new patch on its own, and the CFBot takes only the
attachments of the last message, so it tried to apply a patch that adds
files under src/test/modules/test_progress/ to a tree that does not have
that directory yet. Hence "needs rebase" on the entry.

Here is the whole series, rebased on master (07c73f45063). Nothing
changed in 0001-0005; 0006 is the documentation cross-check I posted an
hour ago.

Rebasing it did turn up something worth mentioning, since it is the sort
of thing this series exists to catch. With only the last three patches
applied on current master, the trace checker fails:

CREATE INDEX 1 violation
parallel GIN build 1
CREATE INDEX CONCURRENTLY 1
REPACK 5
REPACK (CONCURRENTLY) 3

all of them resets that do not reset:

PROGRESS_SCAN_BLOCKS_DONE went from 14 to 1, not to 0
PROGRESS_CREATEIDX_TUPLES_DONE went from 800 to 1, not to 0

Those are the two index-build bugs that 0001 and 0002 fix, so this is
not a regression, it is the checker doing its job on a tree that is
missing the fixes. I am noting it because it is a decent demonstration
of what the series buys: drop two fixes from a five-patch series and the
test tells you exactly which counters stopped being reset, with the log
line that proves it.

With the six applied: make check passes, and test_progress passes while
still reporting the one thing it is meant to report, the REPACK phase
table listing "catch-up" before "rebuilding index" when execution does
the opposite.

Regards,
Manu