fix: remove redundant abort controller (#41)

The signal from this abort controller replaces any user-supplied
signal in forward operations.

When the user supplied signal aborts we call abort on the abort
controller, aborting it's signal.

We do not call `.abort()` on the abort controller for any other
reason, therefore it can be removed and the user-supplied abort
signal can be passed through unmodified.

The redundant abort controller's signal also has the default limit
on the number of event listeners so it causes `"possible EventEmitter
memory leak detected"` warnings in node which people frequently
mistake for an error and file issues about.

Author: achingbrain

packages/verified-fetch/src/verified-fetch.ts

@@ -445,15 +445,6 @@ export class VerifiedFetch {
     [identity.code]: this.handleRaw
   }
 
-  /**
-   *
-   * TODO: Should we use 400, 408, 418, or 425, or throw and not even return a response?
-   */
-  private async abortHandler (opController: AbortController): Promise<void> {
-    this.log.error('signal aborted by user')
-    opController.abort('signal aborted by user')
-  }
-
   /**
    * We're starting to get to the point where we need a queue or pipeline of
    * operations to perform and a single place to handle errors.
@@ -467,12 +458,6 @@ export class VerifiedFetch {
 
     const options = convertOptions(opts)
 
-    const opController = new AbortController()
-    if (options?.signal != null) {
-      options.signal.onabort = this.abortHandler.bind(this, opController)
-      options.signal = opController.signal
-    }
-
     options?.onProgress?.(new CustomProgressEvent<CIDDetail>('verified-fetch:request:start', { resource }))
 
     // resolve the CID/path from the requested resource