When scheduling an automatic reconfig to remove a 'newlyAdded' field, we drop the replication coordinator mutex before actually doing the reconfig (which includes creating the new config for the reconfig). We use the memberId to note which member should have 'newlyAdded' removed. If another reconfig happens in parallel with the automatic reconfig, especially one that moves around the memberIndex of various nodes, it could be easy to add a bug that removes the wrong 'newlyAdded' field. To protect against this type of bug, we check that the configVersion and config term match after the scheduled reconfig actually constructs a new config. We should test this race condition explicitly.