fix(NODE-4763): tryNext not updating resumeToken for a returned update

[Omnicpie]

Description

This PR attempts to fix an issue noticed when using tryNext in which it does not correctly update the resumeToken when updates are received, meaning that if the change stream is resumed it can end up resuming in the past, causing issues.

What is changing?

The change is small and involves changing the tryNext function to use the internal _processChange function which handles updating the resume token before returning the given change. This is used by next already, so seems to be a good solution overall.

What is the motivation for this change?

To prevent issues where resuming the change-stream using tryNext causes the client to go backwards in time, potentially causing issues on systems that use this functionality

NOTE FOR REVIEWERS

I wasn't sure where to add test coverage for this, or what exactly I should call in terms of testing, Happy to add some tests for this functionality if someone can point me in the right direction of the "where and how" to test this.

Double check the following

• Ran npm run check:lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[baileympearson]

Hi @Omnicpie, thanks for the submission. Your right - this fix will need testing. We likely needs tests to confirm that the tryNext() correctly updates the resume token both when there is a document and there is not a document, for both the inital change stream aggregates and subsequent getMores. We have a lot of change stream tests in change_stream.test.ts - if you look at the tests in that file, that should help get you going in the right direction!

Also note that _processChange throws an error if the change is null. So we should only call it if there actually was a change from cursor.tryNext().