In testing, we have observed cases where a deleteMany running while a moveCollection commits returns a StaleConfig error which is retried by mongos, leading to an unexpected value for n in the response (because some of the deletes happened on the donor shard, then the rest of the deletes happened on the recipient shard after the retry, and n only captures the deletes that occurred on the recipient).

We are concerned that similar behavior exists for updateMany where a StaleConfig after a moveCollection to lead it to retry and update the same document twice (once on the donor originally, and once again on the recipient after the retry). However, at the time of writing, this has not been observed to happen in testing.

This ticket is to do the following:
1. Verify whether or not the scenario described above can occur for updateMany.
2. If it can, make updateMany fail with some error that mongos will not retry instead of StaleConfig.