In GraphQL.js working group we discussed and put process in place. But
we never officially wrote down in docs. You can watch this recording
https://youtu.be/BBxc_HmB71I?si=cvdUMI47vBsT9F2y&t=1316 or check the
transcript. These are the changes we agreed in the working group, just
putting them in writing.

---------

Co-authored-by: Benjie <benjie@jemjie.com>

The publish method checks to see if a subsequent result is empty; this
same logic should be employed to suppress pending notices for empty
records.

This has already been achieved for subsequent results that are children
of the initial result, as we generated the pending notices from the list
of initially published records.

For subsequent results that are children of other subsequent results, we
previously generated the pending notice prior to actually publishing.

This change integrates the logic: the publishing method itself returns a
pending notice as required. This results in a bug-fix for subsequent
records of other subsequent records as well as a reduction of code for
subsequent results to the initial result.

if we allow nesting of defers at the same level then we have to handle the case where a defer is completely empty -- not just empty because its fields are also contained within a parent.

this means that collectFields must directly return the new defer usages so that even empty defer usages can be used to create fragments so that we can track their children

removes the need for entire GraphQLResult class and host of helper functions, presumably improving performance in both the non-incremental and incremental cases

this filtering can probably be further improved, as we do not have to check for errors in the path tree higher than the current incremental context's path, if we chose to save that information.

We can stop checking for errors that will "filter" child futures once we have reached the point in the path at which the current incrementalContext was branched.