During addShard, we propagate the setUserWriteBlock state from the cluster to the new shard. We also block new setUserWriteBlock coordinators from running, however we do not drain the ongoing ones. This can lead to the following scenario which leads to the new shard having incorrect userWriteBlock state:

1. start setUserWriteBlock coordinator
2. start add shard
3. commit add shard
4. setUserWriteBlock takes the stable topology region and sends the state to all shards but does not yet write it on the configsvr
5. add shard propagates the old setuserwriteblock state to the new shard
6. setUserWriteBlock writes the new value on the config server

Rather than relying on the stable topology region in the setUserWriteBlock coordinator, we should drain the ongoing coordinators in the addShard command ensuring that the state cannot change while a shard is being added.