Handling TCP connection errors

[mikee47]

There is an ongoing issue with the apparent lack of response when HTTP connections fail, such as with invalid URLs (issue #1937).

PR #1939 was a simple attempt to address this problem, but I'm closing that because this issue requires scoping out properly first and applies to all types of TCP connections, not just HTTP.

When a HTTP request is issued a completed delgate is supplied, which receives a boolean successful parameter. This parameter is false if HTTP parsing fails or the remote connection returns an HTTP error code.

If, when sending the request, a failure occurs in the connection process then the callback is never invoked. This can happen if:

• The server address specified cannot be resolved (DNS failure)
• A TCP connection cannot be made to the server (no service on the specified port)

And probabaly others. Issues are:

• These failures are essentially permanent so retrying the request is generally pointless, but that is what happen and can continue indefinitely
• Diagnosing the issue requires setting DEBUG_VERBOSE_LEVEL=3 and observing output
• There's no mechanism for reporting these failures to an application

My feeling is that invoking the HttpRequest completion callback is not the correct approach here since a failure (successful=false) should only relate to the response from the remote server. Here, the request hasn't actually completed and is still in the queue.

This suggests that a new API for catching such errors would be useful for an application.
We'd need to:

• Decide where to place the API (probably in the TCP classes somewhere)
• How to define the callback, perhaps with a code indicating the cause of failure (e.g. DNS resolution failure)
• Fully document the various callbacks and methods to clarify usage