There is a test failure where:

• an initial syncing node starts an index build
• then initial sync fails
• initial sync restarts, dropping all the replicated databases again before starting cloning again
• and a drop collection runs into an index build in progress invariant

The codepath for hitting the invariant is coming through:

• InitialSyncer::_truncateOplogAndDropReplicatedDatabases
• StorageInterfaceImpl::dropReplicatedDatabases
• DatabaseHolderImpl::dropDb
• invariantFailedWithMsg

DatabaseHolderImpl::dropDb technically expects the caller to have checked for in-progress index builds before calling, which didn't happen. I suppose initial sync finding an index build in-progress at a higher level is also an invariant'ing offense. Maybe think about it a bit more whether some higher level invariant about no index builds in progress should be added, or not.