(SERVER-116) Reuse client instances

Reuse HTTP client instances in the ruby code rather than creating
a new one for every request.
This was a conscious decision made after some discussions among @fpringvaldsen, @cprice404, and myself.

Under the Ruby Puppet master, I had observed that for report requests being made from the master to the target uri of an HTTP report processor that a "Connection: Keep-Alive" header was being included but that the underlying HTTP client implementation in Ruby was always closing the connection after making the request anyway.  So effectively, we were never getting "keep-alive".

With the persistent Java HTTP client implementation, connection keep-alive behavior is controlled the "Connection" header provided with the request.  A "Connection: Keep-Alive" or absent "Connection" header will cause the underlying Apache HTTP client to try to reuse the connection for requests.  Unless we do something like what @fpringvaldsen's change would do here, then, we would end up with connections being reused for requests under Puppet Server whereas they were not under the Ruby Puppet master.

While connection reuse may be beneficial for optimizing performance, doing so would have security implications.  For example, if the request were being made with HTTP basic authentication, it is possible (likely with servers I've seen in the past) that the server might only authenticate the client for the first request received on the connection but not re-authenticate the client for subsequent requests.  If the client's basic authentication credentials were to intentionally change from one request to another for the same target uri, the lack of re-authentication by the server could represent a security hole.

The underlying Apache HTTP client library may have some mitigation for this by checking for and not reusing a connection when a credential change occurs, but I doubt it.  More likely, we may have to do something at the application layer to mitigate for this problem.  This all seemed way to complex to try to take on now, especially given that the backward compatible behavior would be to just avoid keep-alive.

Given the above, I'm okay with @fpringvaldsen's change as is.