test: actually test use of AbortSignal in resolver

The previous test didn't really make use of the fact that the
AbortSignal could be used in the resolver: the only use it made of it
was to call `signal.throwIfAborted` *after* the cancellable promise was
already cancelled. The "This operation was aborted" message that shows
up in the GraphQL response actually came from the cancellable promise,
not the throwIfAborted call. You can see that because if you just
replace `throwIfAborted` with throwing another error (as this commit
does), the test still passed.

Instead, actually make use of the AbortSignal API to observe the abort
explicitly.

Author: glasser

src/execution/__tests__/cancellation-test.ts

@@ -130,9 +130,19 @@ describe('Execute: Cancellation', () => {
       }
     `);
 
+    let aborted = false;
     const cancellableAsyncFn = async (abortSignal: AbortSignal) => {
+      if (abortSignal.aborted) {
+        aborted = true;
+      } else {
+        abortSignal.addEventListener('abort', () => {
+          aborted = true;
+        });
+      }
+      // We are in an async function so it gets cancelled and the field ends up
+      // resolving with the abort signal's error.
       await resolveOnNextTick();
-      abortSignal.throwIfAborted();
+      throw Error('some random other error that does not show up in response');
     };
 
     const resultPromise = execute({
@@ -165,6 +175,8 @@ describe('Execute: Cancellation', () => {
         },
       ],
     });
+
+    expect(aborted).to.equal(true);
   });
 
   it('should stop the execution when aborted during object field completion with a custom error', async () => {