Failover broken when hard exceptions occured when using *Async methods

[Mpdreamz]

When IConnection throws a hard exception in any of the *Async methods before actual async work has been done the async routines in Transport.cs do not properly failover as they only failover properly for tasks in faulted state.

In most cases the exception happens in a way that causes a faulted task to be returned (when reading responses asynchronously) but some of the exception happen earlier with DNS lookups (see #802) these are always synchronously and will throw a hard exception.

This PR also fixes the case where a hard exception during pinging/sniffing using the Async methods could cause a connection not to failover.

The synchronous versions all behave correctly during hard exceptions.

[Mpdreamz]

Updated the PR to also have better MaxRetryException messages:

I.e when you issues a request but all the sniffs on all the nodes failed you now see this instead of nested MaxRetryExceptions

Elasticsearch.Net.Exceptions.MaxRetryException : Sniffing known nodes in the cluster caused a maxretry exception of its own
  ----> Elasticsearch.Net.Exceptions.SniffException : Sniffing known nodes in the cluster caused a maxretry exception of its own
  ----> Elasticsearch.Net.Exceptions.MaxRetryException : Failed after retrying 2 times: 'GET _nodes/_all/clear?timeout=50'. 
InnerException: PingException, InnerMessage: Pinging http://ipv4.fiddler:9201/ caused an exception, InnerStackTrace:    at Elasticsearch.Net.Connection.Transport.Ping(ITransportRequestState requestState) in C:\Projects\NEST\src\Elasticsearch.Net\Connection\Transport.cs:line 91
   at Elasticsearch.Net.Connection.Transport.DoRequest[T](TransportRequestState`1 requestState) in C:\Projects\NEST\src\Elasticsearch.Net\Connection\Transport.cs:line 326
InnerException: PingException, InnerMessage: Pinging http://ipv4.fiddler:9200/ 

Similary when all the pings fail you can clearly see which nodes were pinged and failed:

Elasticsearch.Net.Exceptions.MaxRetryException : Failed after retrying 2 times: 'GET '. 
InnerException: PingException, InnerMessage: Pinging http://ipv4.fiddler:9202/ caused an exception, InnerStackTrace:    at Elasticsearch.Net.Connection.Transport.Ping(ITransportRequestState requestState) in C:\Projects\NEST\src\Elasticsearch.Net\Connection\Transport.cs:line 91
   at Elasticsearch.Net.Connection.Transport.DoRequest[T](TransportRequestState`1 requestState) in C:\Projects\NEST\src\Elasticsearch.Net\Connection\Transport.cs:line 326
InnerException: PingException, InnerMessage: Pinging http://ipv4.fiddler:9201/ caused an exception, InnerStackTrace:    at Elasticsearch.Net.Connection.Transport.Ping(ITransportRequestState requestState) in C:\Projects\NEST\src\Elasticsearch.Net\Connection\Transport.cs:line 91
   at Elasticsearch.Net.Connection.Transport.DoRequest[T](TransportRequestState`1 requestState) in C:\Projects\NEST\src\Elasticsearch.Net\Connection\Transport.cs:line 326
InnerException: PingException, InnerMessage: Pinging http://ipv4.fiddler:9200/ caused an exception, InnerStackTrace:    at Elasticsearch.Net.Connection.Transport.Ping(ITransportRequestState requestState) in 

This PR also includes unit and integration tests to make sure exceptions bubble out the client the same for synchronous and asynchronous calls. We had unit tests for all of these but in practice things behave differently for instance HttpWebRequest by default only reads 65k of error response streams, our new integration caught this and this is now also fixed as off 856ad81.

[Mpdreamz]

Tested this branch under mono too Mono does not support HttpWebRequest.DefaultMaximumErrorResponseLength so we are not calling it if we detect we are running under Mono.