Previously, the test used awaitSyncSource to wait until it was safe to
write to a new primary, which doesn't really make sense. The more
robust way to do it is to call getPrimary().
As a bonus, stopServerReplication is a better way to ensure that
writes don't progagate to a particular secondary than simply
disconnecting that secondary from the primary.
Finally, the test now uses a checkLog to make sure the server has
arrived at the hangDuringBatchInsert fail point, rather than a one
second sleep.
The description of this SERVER ticket describes a nasty race that can
occur if elections happen inbetween two batches during a large
update. (The included test confirms that the race is possible.)
To fix this, we want to check the operation context for interrupts
with each batch, and we need to make sure the check happens _after_
the collection lock gets taken and before the batch
inserts/updates/deletes execute.
A recent change to locking gives us almost exactly this for free: if a
collection lock has to wait, it throws an exception when the operation
context is interrupted, ending the operation. If the lock doesn't
wait, though, there is no check.
This patch adds that check in. Acquiring a lock now always throws if
the operation context is interrupted, which closes the race window in
this bug.
