- Change the behavior of win32_init so that the required initialization
  procedures are not affected by CURL_GLOBAL_WIN32 flag.

libcurl via curl_global_init supports initializing for win32 with an
optional flag CURL_GLOBAL_WIN32, which if omitted was meant to stop
Winsock initialization. It did so internally by skipping win32_init()
when that flag was set. Since then win32_init() has been expanded to
include required initialization routines that are separate from
Winsock and therefore must be called in all cases. This commit fixes
it so that CURL_GLOBAL_WIN32 only controls the optional win32
initialization (which is Winsock initialization, according to our doc).

The only users affected by this change are those that don't pass
CURL_GLOBAL_WIN32 to curl_global_init. For them this commit removes the
risk of a potential crash.

Ref: https://github.com/curl/curl/pull/3573

Fixes https://github.com/curl/curl/issues/3313
Closes https://github.com/curl/curl/pull/3575

The draft-ietf-httpbis-rfc6265bis-02 draft, specify a set of prefixes
and how they should affect cookie initialization, which has been
adopted by the major browsers. This adds support for the two prefixes
defined, __Host- and __Secure, and updates the testcase with the
supplied examples from the draft.

Closes #3554
Reviewed-by: Daniel Stenberg <daniel@haxx.se>

If mbedtls_ssl_get_session() fails, it may still have allocated
memory that needs to be freed to avoid leaking. Call the library
API function to release session resources on this errorpath as
well as on Curl_ssl_addsessionid() errors.

Closes: #3574
Reported-by: Michał Antoniak <M.Antoniak@posnet.com>
Reviewed-by: Daniel Stenberg <daniel@haxx.se>

... and avoid use of static variables that aren't thread safe.

Fixes regression from e9ababd4 (present in the 7.64.0 release)

Reported-by: Paul Groke
Fixes #3572
Closes #3573

I missed to check this in with commit
71786c05, which only disabled the test.
This fixes the actual linker error.

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

Closes #3571

Closes #3564

Detected by scan-build

Fix scan-build warnings, no globals, no silly handle scan. Also remove
handles from the multi before cleaning up.

To avoid scan-build warnings and global variables.

Detected by scan-build

Detected by scan-build

in ftpget, ftpsget and sftpget, so that scan-build stops warning for
potential NULL pointer dereference below!

Detected by scan-build

scan-build warning: Null pointer passed as an argument to a 'nonnull'
parameter

- Save the original conn->data before it's changed to the specified
  data transfer for the connection check and then restore it afterwards.

This is a follow-up to 38d8e1bd 2019-02-11.

History:

It was discovered a month ago that before checking whether to extract a
dead connection that that connection should be associated with a "live"
transfer for the check (ie original conn->data ignored and set to the
passed in data). A fix was landed in 54b201b4 which did that and also
cleared conn->data after the check. The original conn->data was not
restored, so presumably it was thought that a valid conn->data was no
longer needed.

Several days later it was discovered that a valid conn->data was needed
after the check and follow-up fix was landed in bbae24c3 which partially
reverted the original fix and attempted to limit the scope of when
conn->data was changed to only when pruning dead connections. In that
case conn->data was not cleared and the original conn->data not
restored.

A month later it was discovered that the original fix was somewhat
correct; a "live" transfer is needed for the check in all cases
because original conn->data could be null which could cause a bad deref
at arbitrary points in the check. A fix was landed in 38d8e1bd

 which
expanded the scope to all cases. conn->data was not cleared and the
original conn->data not restored.

A day later it was discovered that not restoring the original conn->data
may lead to busy loops in applications that use the event interface, and
given this observation it's a pretty safe assumption that there is some
code path that still needs the original conn->data. This commit is the
follow-up fix for that, it restores the original conn->data after the
connection check.

Assisted-by:  <tholin@users.noreply.github.com>
Reported-by:  <tholin@users.noreply.github.com>

Fixes https://github.com/curl/curl/issues/3542
Closes #3559

Used by debug builds with NSS.

Reverted from 05b100ae

On non-ascii platforms, the chunked hex header was measured for char code
conversion length, even for chunked trailers that do not have an hex header.
In addition, the efective length is already known: use it.
Since the hex length can be zero, only convert if needed.

Reported by valgrind.

Closes #2367

Detected by scan-build (false positive).

Closes #3569

Closes #2905

Closes #2719

Heimdal includes on FreeBSD spewed out lots of them. Less so now.

Closes #3566

Closes #3523

Closes #3109

Rephrase to satisfy scan-build.

This test doesn't link without FTP support after
fc7ab483, which made Curl_fnmatch
unavailable without FTP support.

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

Nobody works on this now.

Closes #3378

Mostly a false positive, but this makes the code easier to read anyway.

Detected by scan-build.

Closes #3563

Detected by scan-build.

Follow-up to 84c10dc1 from earlier today which wrapped a lot of the noisy
debug output in DEBUGF but omitted a few lines.

Ref: https://github.com/curl/curl/commit/84c10dc#r32292900

- Pass an empty string to CURLOPT_ACCEPT_ENCODING to use the default
  supported encodings.

Prior to this change the specific encodings of gzip and deflate were set
but there's no guarantee they'd be supported by the user's libcurl.

... instead of allocating it separately and point to it. It is
fixed-size and always used for each part.

Closes #3561

Convert numerous infof() calls into debug-build only messages since they
are annoyingly verbose for regular applications. Removed a few.

Bug: https://curl.haxx.se/mail/lib-2019-02/0027.html
Reported-by: Volker Schmid
Closes #3552

Closes #3562

Closes #3557

Follow-up to cac0e4a6

Detected by scan-build
Closes #3560