Summary

At the moment drivers handle internally snapshot reads inside a single session when requested. This is done when a session is opened with `snapshot = true`, by saving the `atClusterTime` sent by the server in a private `snapshotTime` property of the `ClientSession`.  `snapshotTime` is then passed in all subsequent read operations to the sever. At the moment, following our spec, this is supported internally and only in the context of a single session. 
Some users have been requesting us to expose `snapshotTime` or at least to allow snapshot reads across different sessions (see linked tickets). 

Example use cases from linked ticket:

• Service A calls Service B.
  • Service B returns the data from MongoDB and the session timestamp.
• Service A then processes the data.
• Possible: Service C changes the data in MongoDB.
• Service A then calls Service B again, this time with the session timestamp from the first call.
  • Service B returns the data from MongoDB with the provided session timestamp, excluding changed data from Service C.

Motivation

Who is the affected end user?

Users who would like to do snapshot reads across different sessions. 

How does this affect the end user?

At the moment users cannot do snapshot reads across different sessions with our public API. 

How likely is it that this problem or use case will occur?

We did not receive many requests for this use case, so this is probably more of an edge case. 

If the problem does occur, what are the consequences and how severe are they?

Users either can't do snapshot reads across sessions, or need to use internal APIs to do so. 

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.

Acceptance Criteria

We need to investigate if there are technical reasons why snapshot reads across sessions should not be supported, and then decide how we would like to expose this in the public API.