Consider moving the Client::setLastOpToSystemLastOpTime logic into the function logic.

A flag must be set in-memory on the index build whether or not to proceed without voting or end the thread after voting successfully or finding the flag set after the fact. commitIndexBuild, if the build has already reached the 'committing' phase, will set the flag and start a new asynchronous thread for the commit; else, the in-memory flag will be set such that the index build discovers it later and bypasses voting, proceeding straight to commit. This is necessary because stalling commit, and thereby stalling replication on the secondary, cannot be permitted to take as long as a network call can potentially take – a matter of seconds, presumably. The alternative would be to make the voteCommitIndexBuild command sent by the secondary have a short enough timeout that we don't mind stalling replication for that amount of time: but this is risky given that determining a reasonable time for all network and replication latencies might be impossible.

The index build thread would exist after finishing voting, as opposed to waiting on a condition variable for the commitIndexBuild signal, as ReplIndexBuildState is currently expecting with its condition variable already set up and waiting to be used – need to change that.

The flag must also be initialized correctly on index build recovery, depending on the persisted state.