As the function doesn't really use the connectdata struct but only the
SessionHanadle struct I modified what argument it wants.

When using the multi interface and connecting to a host name that
resolves to multiple IP addresses, there was no logic that made it
continue to the next IP if connecting to the first address times
out. This is now corrected.

- Show address string from proper buffer in case of connection failure.

- Try next address when inet_ntop() fails.

Reinstate IPV6 build variable that got removed.

The IP version choice was previously only in the UserDefined struct
within the SessionHandle, but since we sometimes alter that option
during a request we need to have it on a per-connection basis.

I also moved more "init conn" code into the allocate_conn() function
which is designed for that purpose more or less.

As this function uses return code 0 to mean that there is no timeout, it
needs to check that it doesn't return a time left value that is exactly
zero. It could lead to libcurl doing an extra 1000 ms select() call and
thus not timing out as accurately as it should.

I fell over this bug when working on the bug 3061535 but this fix does
not correct that problem alone, although this is a problem that needs to
be fixed.

Reported by: Rodric Glaser
Bug: http://curl.haxx.se/bug/view.cgi?id=3061535

The timeout is set for the connect phase already at the start of the
request so we should not add a new one, and we MUST not set expire to 0
as that will remove any other potentially existing timeouts.

Curl_getconnectinfo() is changed to return a proper curl_socket_t for
the last socket so that it'll work more portably (and cause less
compiler warnings).

The correctly extracted errno contents were mistakenly overwritten by a newer
value that wasn't the correct error value.

Bug: http://curl.haxx.se/mail/lib-2010-08/0242.html

When the progress callback is called during the TCP connection, an error
return would accidentally not abort the operation as intended but would
instead be counted as a failure to connect to that particular IP and
libcurl would just continue to try the next. I made singleipconnect()
and trynextip() return CURLcode properly.

Added bonus: it corrected the error code for bad --interface usages,
like tested in test 1084 and test 1085.

Reported by: Adam Light
Bug: http://curl.haxx.se/mail/lib-2010-08/0105.html

When a hostname resolves to multiple IP addresses and the first one
tried doesn't work, the socket for the second attempt may get dropped on
the floor, causing the request to eventually time out. The issue is that
when using kqueue (as on mac and bsd platforms) instead of select, the
kernel removes the first fd from kqueue when it is closed (in trynextip,
connect.c:503). Trynextip() then goes on to open a new socket, which
gets assigned the same number as the one it just closed. Later in
multi.c, socket_cb is not called because the fd is already in
multi->sockhash, so the new socket is never added to kqueue.

The correct fix is to ensure that socket_cb is called to remove the fd
when trynextip() closes the socket, and again to re-add it after
singleipsocket(). I'm not sure how to cleanly do that, but the attached
patch works around the problem in an admittedly kludgy way by delaying
the close to ensure that the newly-opened socket gets a different fd.

Daniel's added comment: I didn't spot a way to easily do a nicer fix so
I've proceeded with Ben's patch.

Bug: http://curl.haxx.se/bug/view.cgi?id=3017819
Patch by: Ben Darnell

Dirk Manske reported a regression. When connecting with the multi
interface, there were situations where libcurl wouldn't store
connect time correctly as it used to (and is documented to) do.

Using his fine sample program we could repeat it, and I wrote up
test case 573 using that code. The problem does not easily show
itself using the local test suite though.

The fix, also as suggested by Dirk, is a bit on the ugly side as
it adds yet another call to Curl_verboseconnect() and setting the
TIMER_CONNECT time.  That situation is subject for some closer
inspection in the future.

Kenny To filed the bug report #2963679 with patch to fix a
problem he experienced with doing multi interface HTTP POST over
a proxy using PROXYTUNNEL. He found a case where it would connect
fine but bits.tcpconnect was not set correct so libcurl didn't
work properly.

(http://curl.haxx.se/bug/view.cgi?id=2963679)

fix printf-style format strings

Fix compiler warning: conditional expression is constant

fix printf-style format strings

  interval even during very slow connects.

  (http://curl.haxx.se/bug/view.cgi?id=2870221) that libcurl returned an
  incorrect return code from the internal trynextip() function which caused
  him grief. This is a regression that was introduced in 7.19.1 and I find it
  strange it hasn't hit us harder, but I won't persue into figuring out
  exactly why.

  SO_SNDBUF to CURL_WRITE_SIZE even if the SO_SNDBUF starts out larger.  The
  patch doesn't do a setsockopt if SO_SNDBUF is already greater than
  CURL_WRITE_SIZE. This should help folks who have set up their computer with
  large send buffers.

  setting a file descriptor non-blocking. Used by the functionality Eric
  himself brough on June 15th.

  well. See change 28 Apr 2009.

  (http://curl.haxx.se/bug/view.cgi?id=2783090) pointing out that on windows
  we need to grow the SO_SNDBUF buffer somewhat to get really good upload
  speeds. http://support.microsoft.com/kb/823764 has the details. Friends
  confirmed that simply adding 32 to CURL_MAX_WRITE_SIZE is enough.

  CURLOPT_LOCALPORT were used together (the local port bind failed), and
  Markus Koetter provided the fix!