Concurrent mapReduces with replace are not supported. As part of the cluster's map reduce logic, we will always drop the output collection then shard it again. Since these two operations are not atomic, it can leads to a race condition where two mapReduces can simultaneously output to the same collection with the same UUID.

With mapReduce A and B, in order:

1. mapReduce A drops the output collection
2. mapReduce B drops the output collection
3. mapReduce A creates the sharded output collection with a generated UUID
4. mapReduce B attempts to shard the output collection, but when doing is told that the collection is already sharded and receives the UUID that mapReduce A generated.

In order to avoid this undefined behavior, no sharded fuzzer suites (specifically: jstestfuzz_sharded_causal_consistency) should run mapReduce with replace.