Serf should try more addresses before giving up on a connection

What steps will reproduce the problem?
1. Use a serf connection to http://localhost/svn/myrepos/ on Windows
2. Or use a serf connection to http://<my-machine>/svn/myrepos/ on Windows 
without setting up DNS
3.

What is the expected output? What do you see instead?
The expected output is that this just works.
Instead users get a connection refused error, because most Windows server 
packages don't enable listening on ipv6 while localhost resolves to both IPv6 
(::1) and IPv4 (127.0.0.1).

As APR (following the relevant RFCs) returns IPv6 addresses before IPv4 
addresses when resolving and serf doesn't try further resolved addresses 
connections that used to work with neon (that does try other addresses) stop 
working.

Clients that properly keep IPv6 enabled are blamed for the problem because 
'TortoiseSVN works'. But TortoiseSVN just disables IPv6 in apr to hide this 
problem from its users.

I don't think we want Chrome-like tricks in serf where ipv4 is tried side by 
side with ipv6 after 0.5 sec timeout, but it would be nice if these non-DNS 
setup usages would start working again.

Original issue reported on code.google.com by bhuijben on 4 Sep 2013 at 1:25

krime / serf

Serf should try more addresses before giving up on a connection #129