Rhai supergraph response callback does not trigger when a broken pipe is encountered

[danpayne17]

Describe the bug
If the caller closes the connection before the router is done sending the response (e.g. broken pipe), the response callback of the supergraph lifecycle event is never triggered. This is an issue because in this callback, we use Rhai to do a number of things:

1. set response headers (this obviously is irrelevant because the pipe is broken so the response isn't going to be sent so we don't need to set these headers)
2. rewrite the errors array in response body, if present (also irrelevant b/c the response is not going to be sent to caller)
3. set response context variables for use in telemetry instrumentation by response_context selectors (these need to be set in order for span tag attributes to be applied as expected; may be related to
   )
4. log the status of the response (e.g. call to n milliseconds to process for this operation name and resulted in these errors) (this is really important as this log statement actually drives Splunk dashboards and this log statement is never made b/c this lifecycle event isn't triggered)
5. log the response body (not super critical but would be nice to still log the response body that would have been sent if the pipe weren't broken)

To Reproduce
Steps to reproduce the behavior:

1. Configure router to execute Rhai scripts during supergraph response callback:

fn supergraph_service(service) {
  const response_callback = Fn("process_supergraph_response");
  service.map_response(response_callback);
}

fn process_supergraph_response(response) {
  print('executing fn process_supergraph_response()');
  tracing_handler::set_supergraph_response_headers(response);
  error_handler::rewrite_extensions_in_supergraph_response(response);
  error_handler::set_response_context_selector_values(response);
  logger::log_response_status(response);
  logger::log_response_body(response);
}

2. Insert code into subgraph resolver so that it waits 10seconds before responding to requests from router
3. Send request to router using curl
4. Cancel request (ctrl-c) while subgraph is waiting to respond which induces a broken pipe error
5. Observe that the process_supergraph_response was never called

Expected behavior
The response callback of the supergraph service is still executed when a broken pipe is encountered, just like other non-200 errors the router encounters (e.g. a 400 BAD REQUEST still executes the callback)

Router:

• OS: Amazon Linux 2023
• Version: 1.37.0

Additional context
None