Right now, the ReplicatedFastCountManager is responsible for at least

1. Starting and stopping the background thread

• startup()
• shutdown()

2. Flushing

• flushSync()
• flushAsync()

3. Reading and writing to the replicated fast count collection

• find()
• _writeOneMetadata()
• _updateOneMetadata()
• _insertOneMetadata()
• _acquireFastCountCollectionForRead()
• _acquireFastCountCollectionForWrite()
• _getDocForWrite()

After we add the timestamp collection, 3. will become increasingly complicated. I propose we create a new abstract class, ReplicatedFastCountStore, that provides the interface for accessing the underlying size/count and timestamp collections (or container). There would be two implementations: one for size/count and one for timestamp. This helps us (1) write better unit tests by being able to test previously private functions and (2) achieve separation of concerns between the background thread and the collections/containers themselves.