Fix "response position" definition; clarify sibling errors on propagation

[benjie]

:: A response position is a uniquely identifiable position in the response
data produced during execution. It is either a direct entry in the {resultMap}
of a {ExecuteSelectionSet()}, or it is a position in a (potentially nested) List
value. Each response position is uniquely identifiable via a response path.

The intention of response position is that it includes things that were elided by error propagation; e.g. if you query { a { b } } and b is non-null and throws, the result will be {a: null} but the error will have path ["a", "b"] indicating the a.b response position even though that position does not actually exist in the response.

(Also: ExecuteSelectionSet() doesn't exist any more.)

Commit 1: clarify definition of response position to include these omitted values.

---

If a response position resolves to {null} because of an execution error which
has already been added to the {"errors"} list in the execution result, the
{"errors"} list must not be further affected. That is, only one error should be
added to the errors list per response position.

But the response position mentioned at the beginning of this paragraph is different to the response position from which the error originated; therefore "only one error should be added to the errors list per response position" is kind of moot. Actually what we mean here is that the response path of the error (i.e. the "path" entry in the error object) should be unique.

Commit 2: clarify it's the "path" of the error that matters, not the position that re-raised it

---

The use of the term "response position" is confusing, because that position might not actually exist in the response if it was omitted due to error propagation.

Commit 3: rename response position to execution position throughout.

---

All of this together clarifies what happens when an error occurs to a nullable sibling of a non-nullable field that triggers error propagation.

[netlify]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	4d6f01b
🔍 Latest deploy log	https://app.netlify.com/projects/graphql-spec-draft/deploys/686ff7c46b446a0008ff9be3
😎 Deploy Preview	https://deploy-preview-1183--graphql-spec-draft.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 project configuration.

[benjie]

Plan from today's WG:

1. open a new PR that clarifies "response position" without renaming to "execution position" (which could be ambiguous w.r.t. visiting fragments?)
2. rebase this change on that PR, so this becomes just the one sentence change
3. see how hard this would be to implement in GraphQL.js and a few other implementations
4. if hard, reject
5. in graphql-toe, throw the last error that matches the path (just reverse the array?) or throw an aggregate error

[yaacovCR]

graphql/graphql-js#4458 not sure if this is the implementation you want to test, I thought it’s the implementation for: #1184