Add client option to override library's http implementation

[owenpearson]

Usage should look something like:

function ablyHttpImplementation(
        method: HttpMethods,
        uri: string,
        headers: Record<string, string> | null,
        params: RequestParams,
        body: unknown,
        callback: RequestCallback
) {
  try {
    // make an http request using the params and some user provided http client
    callback(null, body, responseHeaders, statusCode);
  } catch(err) {
    callback(err);
  }
}

new Ably.Realtime({
  httpImplementation: ablyHttpImplementation,
  // other options...
});

┆Issue is synchronized with this Jira Task by Unito

[sync-by-unito[bot]]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3447

[VeskeR]

Idea came from the suggestion in the next issue https://github.com/ably/ably-js/issues/1131:

peterjuras: Patch the usage of fetch within the code to use import { fetch } from "@forge/api" instead of the global fetch. This also included replacing some usages of a global Header function (e.g. new Header(...).

owenpearson: I don't see us adding explicit support for something like this but it could be an option to add support for a user-provided http request implementation, ie a function passed in as a client option which takes method, body, qsparams, etc and actually makes the request. I would have to have a think about how this would work w.r.t retries/timeouts etc but it likely wouldn't be too complicated.