This ticket tracks a potential improvement on updateMany/deleteMany semantics on Sharded Clusters. Let's do a quick recap of the current semantics of updateMany/deleteMany on Sharded Clusters:

1. If the updateMany/deleteMany is happening inside a TXN -> honors the Shard Versioning Protocol, targeting the shards owning data for the specific filter. All documents impacted by the TXN will be updated or none of them.
2. Else if the updateMany is targeting just one shard due to the filter -> honors the Shard Versioning Protocol, targeting only that shard.
   • pre 8.0: Documents might be updated once or more times if the operation is suspended and, for example, a migration sneaks in, changing the shard version.
   • 8.0 and above: At most once semantics. If the Shard version changes when resuming a suspended update, we will trigger a query plan killed (SERVER-91465)
3. Otherwise: scatter-gather targeting all shards, without honoring the shard versioning protocol. Documents might be updated 0 or more times.

The goal of this ticket is to describe a change of semantics of the step 3 under some kind of guard, taking advantage of the work we did under  SERVER-91465 (only for 8.0 and above). The idea would be that if the guard is enabled, updateMany/deleteMany targeting N shards outside a TXN will honor the shard versioning protocol, targeting the shards owning data for the specified filter. If the shard version changes during the live of these operations on the shards (e.g. a migration sneaks in), the customer will get a QueryPlanKilled error, so they will get at most once semantics (i.e. routers won't retry them). This mean that the application will be in charge of deciding what to do after getting a QueryPlanKilled error.