When working with time series, some operations issue DDL operations directly on the buckets collection. One example of that is $out's rename step (which today does not use ShardingDDLCoordinators, but after SERVER-79661 will).

Today, ShardingDDLCoordinators that operate on the buckets will take the DDL locks on the buckets collection, and never on the view nss. Conversely, coordinators that operate on a timeseries view will take DDL locks on both the view and the buckets, only if it is a sharded timeseries that already exists.

This poses a problem in an scenario where (i) the view does not yet exist, (ii) a ddl operation runs on the buckets, (iii) and a concurrent create occurs on the view nss. In this situation, two conflicting coordinators run concurrently and conflict on acquiring the critical section on the buckets.

A solution to this could be to make a ShardingDDLCoordinator that operates on a buckets collection also acquire the locks for the view nss. A additional upside to this is that it simplifies (removes) this logic in ShardingDDLCoordinator.