Certain failure modes of the SyncClusterConnection to the config server are safe failures (we are sure nothing has been written) - it is incorrect to fail by aborting mongod here since our state is fully known (the migration failed). Rollback and continue instead.
If the config server is offline for a short amount of time during the critical section causing a write error but we're able to reconnect later, we should try to A) verify the write failure on all servers and B) locally rollback the new version, aborting the migration. Currently we fail hard, and rely on the mongod restart for the config reload.
Note this is different from the case when the config servers go down and stay down, since in that case we are unable to read the state of the metadata and so have to terminate.