In SERVER-128992 we attempted to add a new concurrency suite that randomly triggers sharding metadata invalidates.

In doing so we discovered that deletes may inadvertedly return only the last counter of deleted documents after an operation is retried. This is due to the following timeline of events:

1. A delete with {multi: true} is partially applied with some documents having been deleted successfully.
2. At some point the operation encounters a StaleConfig.
3. The operation proceeds to bubble up the failure upwards before doing any sort of partial counter stashing. This is because the operation will only ever set the number of documents returned in the response after a successful execution.
4. The operation is retried because it is a retryable error.
5. The number of documents deleted that is returned to the user is now based on this new execution.