AbortController support

[JoviDeCroock]

This adds support for aborting execution from the outside or resolvers, this adds a few tests and tries to make the support as easy as possible.

Do we want to support having abort support on subscriptions, I guess it makes sense for server-sent events.

I've chosen 2 places to place these interrupts

• executeFieldsSerially - every time we start a new mutation we check whether the runtime has interrupted
• executeFields - every time we start executing a new field we check whether the runtime has interrupted
  • inside of the catch block as well so we return a singular error, all though this doesn't really matter as the consumer would not receive anything
  • this here should also take care of deferred fields

Still have to compare this to the results that graphql-tools/execute comes with

[netlify[bot]]

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

Name	Link
🔨 Latest commit	370d0f1b40c339d7310c5e707c5d661396f2c8ce
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/6718c1e354978300082df3c0
😎 Deploy Preview	https://deploy-preview-4250--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[bot]]

Hi @JoviDeCroock, 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

[ardatan]

When comparing this to graphql-tools/execute I am not sure whether we want to match this behavior, this throws a DomException which would be a whole new exception that gets thrown while normally during execution we wrap everything with GraphQLErrors.

In fetch, when the request is aborted, it throws AbortError as DOMException. I think it uses abortSignal.throwIfAborted under the hood instead of creating a new Error and throw it as you did here, so the AbortSignal decides on what to throw.