Let me preface this by saying that I'm not an expert on all things HTTP. If I say something incorrect, I hope that someone will (politely) correct me and that everything I say here should be taken with a grain of salt and investigated until you're satisfied. With that out of the way, I'll do my best to answer your questions.
First, a clarification. There are two actually distinct things that you're talking about in your first post. The first is connection pooling, and the second is connection persistence. Connection pooling is a means by which requests can be made more efficient by keeping a handful of connections open so that they remain ready for use. This is why you are seeing more than one connection being made. Connection persistence is a rather different kind of optimization which, in HTTP 1.x, is used to keep a given connection active so that it can be reused for multiple requests.
With regards to connection persistence, If the server hosting esi.tech.ccp.is does not support HTTP 2.0 (which includes facilities for multiplexing requests on a single TCP connection), then you are unfortunately stuck with HTTP 1.x's Connection: keep-alive header. This is supposed to allow for the kind of behavior you are hoping for, however in the case of HTTP 1.x, the time during which a connection is allowed to be kept open can be cut short by the server. Some servers will not allow connections to be kept alive or else only allow them to be kept alive for a relatively brief period of time as a denial of service protection.
In this case, I suspect that you have already done everything that can be done at this level to try to use a persistent connection. If the server you are communicating with decides to terminate one of your connections, Hyper will have to establish a new one, but that should be seen as a convenience. The sub-optimal behavior here is a result of how HTTP 1.x is designed. If you do not wish to see multiple connections being made, then you will have to instruct Hyper not to use connection pooling - however that too, I think, should probably be seen as a convenience.