API for forwarding clean-up errors returned from .return() to consumers of execute?

[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.

See: #4142 for an attempt to address (only some!) of the above cases.

[aniruddhaadak80]

@yaacovCR Correctly forwarding .return() is essential for resource cleanup (closing DB connections, stopping subscriptions).
If the upstream source supports return, the executor should definitely call it when the downstream consumer aborts. This is standard AsyncIterator behavior in JS.
If the current implementation drops it "in some cases" (like filtering), that sounds like a leak/bug that should be addressed to ensure robust stream termination.

[yaacovCR]

At this point, we should send .return() in all required scenarios; we should also have test coverage for this. Any missing .return()s or missing/broken tests would be bona fide buggy behavior and we would attempt to patch as soon as possible.