fix(incremental): do not ignore errors from filtered streams

[yaacovCR]

depends on #4141

Early execution may result in non-completed streams after publishing is completed -- these streams must be closed using their return methods. When this occurs, we should pass through any error that occurs in the clean-up function instead of swallowing errors.

Swallowing errors is a bad practice that could lead to memory leaks. The argument in favor of swallowing the error might be that because the stream was "executed early" and the error does not impact any of the returned data, there is no "place" to forward the error.

But there is a way to forward the error, and that's on the next() call that returns { value: undefined, done: true } to end the stream. We will therefore appropriately send all the data and be able to pass through an error. Servers processing our stream should be made aware of this behavior and put in place error handling procedures that allow them to forward the data to clients when they see a payload with { hasNext: false } and then filter any further errors from clients. Servers could also postpone sending { hasNext: false } until the clean-up has been performed, and then optionally send information about the error in the extensions key, if that made sense. It would be up to the server!

[netlify]

✅ Deploy Preview for compassionate-pike-271cb3 ready!

Name	Link
🔨 Latest commit	d6377eb
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/668ec947943e6100087872d0
😎 Deploy Preview	https://deploy-preview-4142--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[github-actions]

Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋

Supported commands

Please post this commands in separate comments and only one per comment:

• @github-actions run-benchmark - Run benchmark comparing base and merge commits for this PR
• @github-actions publish-pr-on-npm - Build package from this PR and publish it on NPM

[yaacovCR]

There are 2-6 cases in which we might want to call .return() on an asyncIterator being used to iterate through a list.

1. If a non-nullable list item errors, and we abort iteration.
   1. without the use of the @stream directive or with erroring indices prior to hitting initialCount
   2. without the use of the @stream directive or with erroring indices prior to hitting initialCount, even when the entire list is not included in the response anyway because of null bubbling from somewhere else...
   3. with the use the @stream directive with errors within streamed items, i.e. for nonreconcilable stream items.
   4. when streams are "filtered" i.e. when early execution results in asyncIterators that are encountered but not actually send to the client.
2. When using incremental delivery, when .return() is called on the subsequentResults iterator explicitly, we should forward that to the underlying stream asyncIterator.
   1. for streams that would have been sent to the client
   2. for streams that would have been "filtered"

In each of these scenarios, we would have to think about how to forward errors from .return() to the client if we would like to do so. Right now, the current state is that we are not tackling how to return errors from .return() at all with respect to (1), and that's probably how it should stay until users of graphql-js can weight in on what this API should look like.