Long delay starting replicator, for big databases

A developer reports long delays, up to several minutes, when a replicator starts before it transfers any documents. During this time there is a large amount of disk I/O. This is a regression in 2.6.

"I have ... a dev app that has ~1 million documents and is 1.3GB and a staging app that has ~5 million documents and is 4.3GB. The dev app reads about 1GB before pulling documents, whereas the staging app reads 40GB before pulling documents. Reading 40GB takes about 10 minutes.

A screenshot from the Instruments app attached to his post shows the I/O is caused by c4enum_next, called by litecore::repl::Replicator::_start. There's a missing stack frame in between, which must be Replicator::_findExistingConflicts.

So this is caused by the scan for pre-existing conflicted documents. Unfortunately there's no index to assist the query C4DocumentEnumerator runs, so it's doing a linear scan of the entire table.