Split keepalive from pipelining in HTTP connections (bug https://bugs.ec...

...lipse.org/bugs/show_bug.cgi?id=434402). A new property 'pipelining' is added to HttpClient to disable HTTP pipelining (by default, pipelining is true to maintain backwards compatibility)
Well, there's actually a bug in keep alvie support, specifically it doesn't respect the 'Connection: close' header returned in a response.  In that case it shouldn't put the connection back into the pool and shouldn't pass the connection to a waiter in the wait queue.  

I have a test that uses a connection pool size of one that fires two requests simultaneously to a server that passes back 'Connection: close' (and subsequently closes the connection).  In that case every other request gets a request timeout because the non-persistent connection is being passed directly to the waiting request.

Regarding pipelining specifically, I think it's been pointed out elsewhere that the Vertx pipelining implementation doesn't follow the RFC.  Specifically it does perform a resend on connection close, or at least I haven't found the code and if it did do that I wouldn't get a request timeout in the test listed above with pipelining enabled.  

Beyond whether Vert.x's implementation of pipelining is correct or not, pipelining isn't always well supported be servers and there are lots of implications in using it.  A caller needs to understand which of it's calls are idempotent so that it  knows it won't have an unintended side effect due to pipelining. Because of this I would think that enabling pipelining should be a consciences effort by the developer using the library and not a default.  Also, since the non-Java language binders don't currently expose the setPipelining method you're forcing it on all non-Java users with no ability to disable it but to also disable keep alive.