With change stream optimization enabled, if we push down a $match that filters out an invalidate message from the stream, we still ensure that the stream is invalidated via our new ChangeStreamInvalidation exception. But we also provide the invalidate resume token as the final PBRT to the client, so they can optionally use it with startAfter to restart the stream after the invalidation. But in this case, even if they restart the stream with the exact same pipeline, DSCSEnsureResumeTokenPresent will fail to see the token in the resumed stream and will throw.

We should make sure that we support resuming in all cases where the resume pipeline is identical to the original pipeline, including the case of startAfter with an invalidate token.