Introduction of ares_library_init() and ares_library_cleanup()

  no_proxy which made it not skip the proxy if the URL entered contained a
  user name. I added test case 1101 to verify.

Extend displaying of logfiles upon first server start-up failure for http, https, ftp, ftps and tftp test harness servers.

thinking straight.

unconditionally

release, or bump or whatevere

the function we should use, while both curl_multi_socket() and
curl_multi_socket_all() should be killed!

I just posted about this decision on the curl-library list.

  only expose functions starting with ares_.

not in the mood enough to fight this now.

65. When doing FTP over a socks proxy or CONNECT through HTTP proxy and the
  multi interface is used, libcurl will fail if the (passive) TCP connection
  for the data transfer isn't more or less instant as the code does not
  properly wait for the connect to be confirmed. See test case 564 for a first
  shot at a test case.

badness in the code flow even for the socks case.

to it in the actual connect call and not asynchronously.

the multi interface, which currently doesn't work because of how the data
connection is not waiting for connect before it tries to do proxy magic.

  of streams that had some parts (legitimately) missing. We now provide and use
  a proper cleanup function for the content encoding submodule.
  http://curl.haxx.se/mail/lib-2009-05/0092.html

  at https://bugzilla.redhat.com/show_bug.cgi?id=453612#c12

  If an incorrect password is given while loading a private key, libcurl ends
  up in an infinite loop consuming memory. The bug is critical.

  as reported by Ebenezer Ikonne (on curl-users) and Laurent Rabret (on
  curl-library). The transfer was mistakenly marked to get more data to send
  but since it didn't actually have that, it just hung there...

KEEP_RECV to better match the general terminology: receive and send is what we
do from the (remote) servers. We read and write from and to the local fs.