- Save a parallel transfer's result code only when it fails and the
  transfer is not being retried.

Prior to this change the result code was always set which meant that a
failed result could be erroneously discarded if a different transfer
later had a successful result (CURLE_OK).

Before:

> curl --fail -Z https://httpbin.org/status/404 https://httpbin.org/delay/10
> echo %ERRORLEVEL%
0

After:

> curl --fail -Z https://httpbin.org/status/404 https://httpbin.org/delay/10
> echo %ERRORLEVEL%
22

Closes #xxxx

Closes https://github.com/curl/curl/pull/6920

UTM parameters leak referrer and various marketing/tracking information
even if these would normally be stripped by website or client policy.
This link also works fine without them. Also took the opportunity to
update the URL to the one pointed to by the previous one via permanent
redirect.

Reviewed-by: Daniel Stenberg
Closes #6919

When the host name in a URL is given as an IPv4 numerical address, the
address can be specified with dotted numericals in four different ways:
a32, a.b24, a.b.c16 or a.b.c.d and each part can be specified in
decimal, octal (0-prefixed) or hexadecimal (0x-prefixed).

Instead of passing on the name as-is and leaving the handling to the
underlying name functions, which made them not work with c-ares but work
with getaddrinfo, this change now makes the curl URL API itself detect
and "normalize" host names specified as IPv4 numericals.

The WHATWG URL Spec says this is an okay way to specify a host name in a
URL. RFC 3896 does not allow them, but curl didn't prevent them before
and it seems other RFC 3896-using tools have not either. Host names used
like this are widely supported by other tools as well due to the
handling being done by getaddrinfo and friends.

I decided to add the functionality into the URL API itself so that all
users of these functions get the benefits, when for example wanting to
compare two URLs. Also, it makes curl built to use c-ares now support
them as well and make curl builds more consistent.

The normalization makes HTTPS and virtual hosted HTTP work fine even
when curl gets the address specified using one of the "obscure" formats.

Test 1560 is extended to verify.

Fixes #6863
Closes #6871

... by fixing macros to do-while constructs and moving out the calls to
"break" outside of the actual macro. It also fixes the problem where the
macro was used witin a loop and the break didn't do right.

Reported-by: Emil Engler
Fixes #6847
Closes #6909

No longer considered experimental.

Closes #6700

... previously they were supported if a TLS library would (unexpectedly)
still support them, but from this change they will be refused already in
curl_easy_setopt(). SSLv2 and SSLv3 have been known to be insecure for
many years now.

Closes #6773

Instead output a warning about it and continue with the defaults.

These SSL versions are typically not supported by the TLS libraries since a
long time back already since they are inherently insecure and broken. Asking
for them to be used will just cause an error to be returned slightly later.

In the unlikely event that a user's TLS library actually still supports these
protocol versions, this change might make the request a little less insecure.

Closes #6772

Make sure one of the azure jobs has jsonlint installed so that the test
runs there.

Ref: #6905