Investigate behavior for Ruby http client request failures

In SERVER-517, we did some work in the Ruby HTTP client handler to re-map any HttpClient exceptions thrown by clj-http-client into Ruby SocketErrors. This was done to allow Ruby users of Puppet::Network::HttpPool instances to be able to catch errors in a generic way, whether running under MRI Ruby or under JRuby in Puppet Server.

We should spend some more time on this to see how the exceptions are delivered to callers when running under MRI Ruby. Specifically, what are the exception classes and message contents for different types of request failures, for example:

• Failure to connect due to the server not listening
• Failure to connect due to an SSL handshake issue, either from the client or server
• Failure to connect to a server after a timeout.
• Successful connection but failed to receive response due to a read timeout.
• ... and maybe some others?

My guess is that the MRI Ruby stack might give more contextual information at the outer exception layer than what is generically captured via the JRuby/Puppet Server stack today.

This ticket may ultimately lead to some further work in the Puppet Server http_client code around the exception remapping - maybe needing to drill down into nested Java exception causes returned from clj-http-client in order to produce a more suitable exception for Ruby users. This may also lead into further work needing to be done in clj-http-client itself to provide the additional context to produce more useful exceptions.

If we find that the Puppet Server work would need to reference Apache http-client library classes directly, we should file a follow-on ticket to explore some clj-http-client layer remapping of the Apache exceptions into standard Java layer equivalents so that clients aren't forced to be coupled to Apache http-client classes that may change in the event that clj-http-client were ever migrated to a different underlying library.