Rely on recovery for index statistics not flushed to counts store

There was a race condition between committing transactions and flushing
the counts store as part of taking an index online. This problem is
related to the fact that an index comes online non-transactionally, so
when that process tries to flush the counts store it would read the
lastCommittedTransactionID from the store, but that transaction might
not have been fully applied yet. We write the lastCommittedTransactionID
after we have successfully written the transaction to the log, but
before the transaction has been applied to the store files. With the
counts rotated before the transaction commits, the committing
transaction would encounter a counts store that already thinks the
transaction in question has been committed, and thus reject it.

Since flushing the counts store when taking an index online is only an
optimisation to avoid having to re-sample the index on recovery, it is
safe to simply remove the flushing on the counts store and pay the cost
of slightly longer recovery time instead.
Merge pull request #3543 from davidegrohmann/2.2-do-not-flush-counts-after-index-population

Rely on recovery for index statistics not flushed to counts store