When running a collMod with a timeseries granularity change over a tracked collection, the collMod DDL coordinator blocks CRUD operations for all shards that have data for that collection. It appears this is done because if a timeseries collection is sharded on time, the routing of queries also depends on the granularity value in addition to the chunk bounds, so that the Shard Version Protocol is not sufficient.

Since this does not apply to time series collection that are sharded on meta instead of time (and sharding on time is deprecated since v8.0), we should investigate if that's the only reason, if so we can avoid blocking CRUD if timeField is not part of the shard key.

This would mitigate both availability issues (such as SERVER-108801 where collMod can become stuck while CRUD is blocked) and consistency issues (such as the fix for SERVER-107819, where collMod aborts index builds since it can not wait while CRUD is blocked).