The existing jstest overrides for read/write concern (used by various passthrough suites) currently cowardly fail if a jstest sets an explicit read/write concern that differs from what the override is trying to set.

• https://github.com/mongodb/mongo/blob/r4.3.3/jstests/libs/override_methods/set_read_and_write_concerns.js#L117-L121
• https://github.com/mongodb/mongo/blob/r4.3.3/jstests/libs/override_methods/set_read_and_write_concerns.js#L146-L151
• https://github.com/mongodb/mongo/blob/r4.3.3/jstests/libs/override_methods/network_error_and_txn_override.js#L447-L452

However, in the presence of cluster-wide read/write concern defaults, it is now sometimes necessary for jstests to send an explicit RWC which is the implicit server default, in order to ensure correctness when the CWRWC default has been set to something else. This includes common code in ReplSetTest/ShardingTest (see SERVER-45651 and SERVER-45908). This causes jstests in the affected passthrough suites to fail.

The overrides should be relaxed such that if a command has explicit RWC which is an implicit server default (ie. {w: 1}, {w: 1, wtimeout: 0}, {level: "local"}, or {level: "available"}), then it gets replaced by the override (rather than the cowardly refusal). This is still correct because the explicit RWC being replaced is identical to the behaviour that would have occurred if it had been omitted, and because the overrides are always used to upgrade to stronger RWC (and never weaker).