As part of SERVER-122287 we decided to close the task as Won't Fix since the refresh itself will work fine from within the coordinator with the use of dual feature flags.

However, this raised an interesting observation that corrdinators are performing filtering metadata refreshes as well as accessing the local CollectionCatalog via AutoGet/Shard Role acquisitions on the shard executing them. This is most definitely a recipe that complicates changes for future projects as coordinators should conceptually be executable by any node without relying on the durable state of the node executing it (excluding the durable state to track the coordinator phases).

In other words, coordinators should:

1. Not rely on the filtering metadata nor trigger refreshes to it, rather they should directly work with the CSRS to fetch whatever they need to run regarding the sharding metadata.
2. Not rely on the local CollectionCatalog.

An example of a DDL that breaks both of these assumptions is refineShardKey since it first does a refresh and then triggers an AutoGet call to see if the collection exists on the executing node instead of calling listCollections on the db primary shard.