Speed limits (from CURLOPT_MAX_RECV_SPEED_LARGE &
CURLOPT_MAX_SEND_SPEED_LARGE) were applied simply by comparing limits
with the cumulative average speed of the entire transfer; While this
might work at times with good/constant connections, in other cases it
can result to the limits simply being "ignored" for more than "short
bursts" (as told in man page).

Consider a download that goes on much slower than the limit for some
time (because bandwidth is used elsewhere, server is slow, whatever the
reason), then once things get better, curl would simply ignore the limit
up until the average speed (since the beginning of the transfer) reached
the limit.  This could prove the limit useless to effectively avoid
using the entire bandwidth (at least for quite some time).

So instead, we now use a "moving starting point" as reference, and every
time at least as much as the limit as been transferred, we can reset
this starting point to the current position. This gets a good limiting
effect that applies to the "current speed" with instant reactivity (in
case of sudden speed burst).

Closes #971

Especially in regards to the multiplexing part.

...and discuss a possible solution.

darwinssl: add documentation stating that the --cainfo option is intended for backward compatibility only

In other news, I changed one other reference to "Mac OS X" in the documentation (that I previously wrote) to say "macOS" instead.

With HTTP/2 each transfer is made in an indivial logical stream over the
connection, making most previous errors that caused the connection to get
forced-closed now instead just kill the stream and not the connection.

Fixes #941

This reverts commit 9cb1059f.

As discussed in #835 SOCKS5 supports IPv6 proxies and destinations.

...and removed some old ones

Follow-up to a96319eb (document the new behavior)

The server developer.netscape.com does not resolve into any
ip address and can be removed.

Added in 5fce88aa

After a few wasted hours hunting down the reason for slowness during a
TLS handshake that turned out to be because of TCP_NODELAY not being
set, I think we have enough motivation to toggle the default for this
option. We now enable TCP_NODELAY by default and allow applications to
switch it off.

This also makes --tcp-nodelay unnecessary, but --no-tcp-nodelay can be
used to disable it.

Thanks-to: Tim Rühsen
Bug: https://curl.haxx.se/mail/lib-2016-06/0143.html

Closes #835

Closes #768

Closes #662

Closes #885