DRIVERS-1819 Snapshot session sends readConcern with all commands even writes

[ShaneHarvey]

This PR requires drivers to send readConcern with all commands in a snapshot session (even writes). This effectively bans all unsupported operations in a snapshot session because the server will reject commands that do not support readConcern.level "snapshot". For example:

MongoDB Enterprise repl0:PRIMARY> db.runCommand({'listCollections': 'test', readConcern: {level: 'snapshot'}})
{
"ok" : 0,
"errmsg" : "Command listCollections does not support { readConcern: { level: \"snapshot\", provenance: \"clientSupplied\" } } :: caused by :: read concern not supported",
"code" : 72,
"codeName" : "InvalidOptions"
}
MongoDB Enterprise repl0:PRIMARY> db.runCommand({'insert': 'test', documents: [{}], readConcern: {level: 'snapshot'}})
{
"ok" : 0,
"errmsg" : "Command insert does not support { readConcern: { level: \"snapshot\", provenance: \"clientSupplied\" } } :: caused by :: read concern not supported",
"code" : 72,
"codeName" : "InvalidOptions"
}

I've added tests for a variety of methods to ensure we send readConcern.level correctly and that the server rejects the field. I can add tests for more operations once we decide this approach is reasonable.

[jyemin]

I like the approach. I implemented the changes in the Java driver, though, and some of the test fail on sharded 5.0 clusters. For example "Server returns an error on insertOne with snapshot" fails because the server does not throw an exception. I confirmed in the shell:

MongoDB Enterprise mongos> db.runCommand({'insert': 'test', documents: [{}], readConcern: {level: 'snapshot'}})
{
	"n" : 1,
	"ok" : 1,
	"$clusterTime" : {
		"clusterTime" : Timestamp(1625064185, 7),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	},
	"operationTime" : Timestamp(1625064185, 7)
}

Not sure what we should do. I suppose we could disable these tests on sharded clusters and report this as a server bug.

Update: I just noticed that 4 of the 9 tests in snapshot-sessions-unsupported-ops pass (findOneAndUpdate, listDatabase, listCollections, listIndexes), so the server is not consistent with this enforcement.

[ShaneHarvey]

Ah that's 100% correct. I had forgot to check the sharded test results. I also see mongos not validating readConcern on insert, update, and delete commands. I just opened SERVER-58176.

[jyemin]

Cool. Can you re-arrange the tests so that they are skipped on sharded clusters for now?

[ShaneHarvey]

Can you re-arrange the tests so that they are skipped on sharded clusters for now?

Done.

[ShaneHarvey]

@ajdavis Does this approach look good to you? For more background see the description in SERVER-58176.

[jyemin]

This required a change in approach for the implementation, but it wasn't too big a deal in the end. All the tests are passing.

LGTM

[ajdavis]

I'd add, "even commands like insert and update that do not accept a readConcern. This ensures the server will return an error for invalid operations, such as writes, within a session configured for snapshot reads." Make the implicit explicit.

[ShaneHarvey]

Done.

[ajdavis]

Yeah, if we can fix SERVER-58176 in time, then I like this approach a lot.

[ShaneHarvey]

Thanks for the quick reviews!

[ShaneHarvey]

Done.

[rstam]

Makes sense. LGTM