feat: allow passing a http.Agent to ipfs-http-client in node

[achingbrain]

Right now no http.Agent is used for requests made using the http client in node, which means each request opens a new connection which can end up hitting process resource limits which means connections get dropped.

The change here sets a default http.Agent with a keepAlive: true and maxSockets of 6 which is consistent with browsers and native apps.

The user can override the agent passed to the ipfs-http-client constructor to restore the previous functionality:

const http = require('http')
const createClient = require('ipfs-http-client')

const client = createClient({
  url: 'http://127.0.0.1:5002',
  agent: new http.Agent({
    keepAlive: false,
    maxSockets: Infinity
  })
})

Refs: #3464

[Gozala]

Looks good to me. I would however suggest making keepAlive and makSockets (or better yet maxConnections) as options directly instead of tying it all to the Agent, so it is more immune to changes in the implementation (e.g. switching to library that does not allow providing Agent).

[achingbrain]

I would however suggest making keepAlive and makSockets (or better yet maxConnections) as options directly instead of tying it all to the Agent

It's all a tradeoff. If we specify all agent options as part of our API, we need to ensure compatibility with whatever options are available in a given version of node or otherwise handle the incompatibility. If we start renaming options, we break compatibility with node and users have to learn our API instead of using the one that is familiar to them.

I think it's better to just treat the Agent as an opaque datatype and pass it through to the underlying request library. This way people can also use experimental Agent implementations should they wish to, and we are none the wiser.

switching to library that does not allow providing Agent

I'm not sure we'd ever do this, there would be no way to control connection pooling in node, since it's all done by Agents. Unless I suppose the library implemented it's own HTTP client over raw sockets but the chances of this seem small.