During rollbacks we clear the shard registry (and for some reason also in the observer) for the config server. This seems to be because under certain circumstances we might read local data.

We should ensure we're reading consistent data, which implies to always read with a majority read concern, without exceptions, so we don't have to clear the shard registry in the rollback code nor in the rollback observer. We should also ensure that all operations in add / remove shard must be done with a majority write concern.

One implication of this is that a secondary with a warmed shard registry, in the presence of a rollback while becoming a primary, it would clear the shard registry, and any service that tries to contact a shard on startup that uses the non causally consistent API will fail with a shard not found error.