Currently, the _currentCommittedSnapshot is stored as an optime, which requires us to construct a term for it in certain cases when we don't set it based on a real optime in the oplog. This makes the stable timestamp calculation more complex than necessary, since the stable timestamp doesn't require any term information. We should consider refactoring the currentCommittedSnapshot to be a Timestamp, so that we don't need to construct a "virtual" optime. This would likely require re-wiring certain aspects of how we do write concern waiting logic, and may require some changes to how we provide this value as the "config optime" to sharding.

Fundamentally, a timestamp should include sufficient information for the purposes that the committed snapshot is used for i.e. majority readers only use a timestamp for reads, and when waiting for an operation to commit at a certain write concern, timestamps should be sufficient to totally order operations in a local node log, so inclusion of the term shouldn't be strictly necessary.