This change makes change streams fail fast(er) in case the stream was opened with a resume token from a different change stream and the new stream's match expression includes a $match stage that filters out the original event.

Example:
1. First change stream is opened with no match expression.
2. First change stream returns an arbitrary event. The event's resume token is noted.
3. A second change stream is opened, using the resume token from the first stream, but with an additional $match expression that excludes the event that originally produced the resume token.

The second change stream will then never observe the event that produced the original resume token, so it will always fail.

Before this change, the second change stream would fail when returning the first event that matched the stream's $match expression. The stream would not return any events, but fail sooner or later, depending on the selectivity of the stream's $match expression.

With this change, the second change stream can fail faster. Whenever it can establish that the oplog scan passed the resume token point, but the resume token itself was not observed, the stream will fail.

This is a (small) change in behavior, but rather an optimization. It avoids lengthy and unproductive oplog scans for streams that ultimately fail anyway.

Description of Linked Ticket

The DSCSEnsureResumeTokenPresent stage must wait until it actually sees an event in the resumed stream before determining whether the client's requested resume point was present or not. If the filter used to resume the stream is very narrow, the stream may run for an indeterminate amount of time before eventually throwing. We should improve this so that the stream fails-fast in such cases.