- In the case of recv error, limit returning 'connection still in place'
to EINPROGRESS, EAGAIN and EWOULDBLOCK.

This is an improvement on the parent commit which changed the openssl
connection check to use recv MSG_PEEK instead of SSL_peek.

Ref: https://github.com/curl/curl/commit/856baf5#comments

Calling SSL_peek can cause bytes to be read from the raw socket which in
turn can upset the select machinery that determines whether there's data
available on the socket.

Since Curl_ossl_check_cxn only tries to determine whether the socket is
alive and doesn't actually need to see the bytes SSL_peek seems like
the wrong function to call.

We're able to occasionally reproduce a connect timeout due to this
bug. What happens is that Curl doesn't know to call SSL_connect again
after the peek happens since data is buffered in the SSL buffer and thus
select won't fire for this socket.

Closes #795

Only protocols that actually have a protocol registered for ALPN and NPN
should try to get that negotiated in the TLS handshake. That is only
HTTPS (well, http/1.1 and http/2) right now. Previously ALPN and NPN
would wrongly be used in all handshakes if libcurl was built with it
enabled.

Reported-by: Jay Satiro

Fixes #789

Sometimes, in systems with both ipv4 and ipv6 addresses but where the
network doesn't support ipv6, Curl_is_connected returns an error
(intermittently) even if the ipv4 socket connects successfully.

This happens because there's a for-loop that iterates on the sockets but
the error variable is not resetted when the ipv4 is checked and is ok.

This patch fixes this problem by setting error to 0 when checking the
second socket and not having a result yet.

Fixes #794

Reported-by: Oleg Pudeyev and fuchaoqun

Fixes #648

Reported-by: rcanavan
Assisted-by: Isaac Boukris
Closes #785

Closes #727

Mention possible content-length mismatch with sum of bytes reported
by write callbacks when auto decoding is enabled.

See #785

- Move the existing scheme check from tool_operate.

In the case of --remote-header-name we want to parse Content-disposition
for a filename, but only if the scheme is http or https. A recent
adjustment 0dc4d8e4 was made to account for schemeless URLs however it's
not 100% accurate. To remedy that I've moved the scheme check to the
header callback, since at that point the library has already determined
the scheme.

Bug: https://github.com/curl/curl/issues/760
Reported-by: Kai Noda

to make it obvious to users trying to use the feature with TLS backends
not supporting it.

Discussed in #781
Reported-by: Travis Burtrum

... not used by any test yet but can be used stand-alone.

Closes #786

As discussed in #785

Reported-by: mgendre
Closes #784

Closes #675

curl_printf.h defines printf to curl_mprintf, etc. This can cause
problems with external headers which may use
__attribute__((format(printf, ...))) markers etc.

To avoid that they cause problems with system includes, we include
curl_printf.h after any system headers. That makes the three last
headers to always be, and we keep them in this order:

 curl_printf.h
 curl_memory.h
 memdebug.h

None of them include system headers, they all do funny #defines.

Reported-by: David Benjamin

Fixes #743

Mostly because they're not needed, because memdebug.h is always included
last of all headers so the others already included the correct ones.

But also, starting now we don't want this to accidentally include any
system headers, as the header included _before_ this header may add
defines and other fun stuff that we won't want used in system includes.

It does open up a miniscule risk that one of the other protocols that
libcurl could use would send back a Content-Disposition header and then
curl would act on it even if not HTTP.

A future mitigation for this risk would be to allow the callback to ask
libcurl which protocol is being used.

Verified with test 1312

Closes #760

This script now also scans src/tool_getparam.c, docs/curl.1 and
src/tool_help.c and will warn if any of them lists a command line option
not mentioned in one of the other places.

In commit 2e42b0a2 (Jan 2008) we made the option "--socks" deprecated
and it has not been documented since. The more explicit socks options
(like --socks4 or --socks5) should be used.

It was mentioned as deprecated already in commit ae1912cb from
1999. It has not been documented in this millennium.