AbortController support (#4250)

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

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.

Supersedes #3791
Resolves #3764

Co-authored-by: yaacovCR <[email protected]>

Author: JoviDeCroock

integrationTests/ts/tsconfig.json

@@ -1,7 +1,13 @@
 {
   "compilerOptions": {
     "module": "commonjs",
-    "lib": ["es2019", "es2020.promise", "es2020.bigint", "es2020.string"],
+    "lib": [
+      "es2019",
+      "es2020.promise",
+      "es2020.bigint",
+      "es2020.string",
+      "DOM"
+    ],
     "noEmit": true,
     "types": [],
     "strict": true,

package-lock.json

@@ -62,7 +62,7 @@
     "@svgr/webpack": "8.1.0",
     "@types/chai": "4.3.19",
     "@types/mocha": "10.0.7",
-    "@types/node": "22.5.4",
+    "@types/node": "22.7.7",
     "@typescript-eslint/eslint-plugin": "8.4.0",
     "@typescript-eslint/parser": "8.4.0",
     "c8": "10.1.2",