feat(execution): expose partial result on abort errors

[yaacovCR]

When execution is aborted while work is still resolving, the executor previously rejected with only the abort reason. That loses access to any response data and errors that execution can still produce while unwinding the in-flight operation.

This PR wraps pre-result aborts in AbortedGraphQLExecutionError and attach the partial result as abortedResult. If the response has already been produced, abortedResult is that response value. If root execution is still pending, abortedResult is the original execution promise so callers can await the eventual partial response separately from the abort rejection.

For example, if a query aborts while a field resolver is pending, execute() rejects with the original abort reason as the error message and cause, while error.abortedResult later resolves to a response such as { data: { blocker: null }, errors: [{ message: 'Aborted!', path: ['blocker'] }] }.

[Incremental execution follows the same pattern for the pending initial result, but aborts after the initial incremental payload continue to surface as rejection of next calls on the subsequentResults iterator (without this new wrapper).
abortedResult is usually a a Promise rather than a value because since the execute promise rejects immediately, execution has not finished.]

It may sometimes be a value, i.e. if the executor aborted internally during synchronous execution, which currently can happen if a resolver triggers the external abort signal or if there is a developer error, such as using a schema or query with defer/stream directives when using execute (instead of using experimentalExecuteIncrementally).

@phryneas => Was this your original suggestion on Discord at some point?

[vercel]

@yaacovCR is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[phryneas]

Just saw this, sorry. I honestly don't remember anymore :)