Improve management of Elasticsearch client socket pools

[gsoldevila]

Currently, every time we instantiate elasticsearch-js's Client class, we are creating a new HTTP(s) Agent that is capable of connecting to multiple origins, and managing its own pool of sockets.

In practice, what that means is if we have two Client instances that connect to the same ES nodes, they will NOT be sharing the same pool of sockets. We will not benefit from idle sockets, and eventually we will have to establish a few more secure connections to ES (aka more TCP + TLS handshakes). Also, it makes things very difficult if we want to track / limit maximum number of open connections, as we don't have control of which Agent instances / sockets pools exist.

We want to be able to group the Client instances logically by domain (e.g. those that are intended for data retrieval, those that are for monitoring purposes, etc). This will allow:

• controlling which pools of sockets exist at a certain point in time.
• reusing HttpConnections (less pools means less active sockets, less idle sockets, and less TCP+TLS handshakes).

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[rudolf]

Although we can work around it for now, I've created an upstream issue for Elasticsearch-js elastic/elasticsearch-js#1740