If we execute a reconfig from C1 => C2, and then try to execute a reconfig from C2 => C3, we must ensure that all ops committed in configs prior to C2 are committed in C2 and that C2 is committed before moving to C3. If C3, however, doesn't actually change the voting member set of the config, we can bypass the safety checks when moving from C2 => C3, since the config is essentially a no-op with respect to member set changes. The next time we do a reconfig that changes the voting member set, we will make sure the safety checks are satisfied. This ensures that all previously committed ops and configs are committed before moving to a config with different members.

This is an optimization that could make certain reconfigs less costly since they won't need to wait for oplog commitment or config replication. For example, changing the election timeout or changing the priority of a node.