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.

The alternative we could come up with would be to distinguish between committed and applied transactions, and that seems like a much more complicated change, that wouldn't give much benefit. It is also possible that such a solution would have other unforeseen complications that we would have encountered, had we started down that route.

If we find later that we actually want to enforce flushing the counts store after an index comes online, the appropriate way to do that would seem to be to force a log rotation. That would work since it has the appropriate synchronizations in place.