Add a barrier sync to ensure we get the WINDOW_UPDATE and the DATA
frames in the expected order.

We could still trigger the integer underflow condition in #2349 by
supplying a padding length equal to the frame size.

Fixes: #2350

In a sequence of HEADERS and CONTINUATION frames, the END_STREAM flag is
set in the HEADERS frame, and the END_HEADERS flag is set in the last
CONTINUATION frame.

Make sure we flag the request as scheduled when dispatched from the h/2
Upgrade code.

Without this, the h/2 code will happily clean it up once the client
hangs up even though it is still being processed in a different thread.

Fixes: #2310

This adds a call to VHT_Fini just before we let go of the h2_sess in
h2_del_req.

Unchecked decoding of the padding length and also the priority flag
turns into an integer underrun when the input length is smaller than
what we end up subtracting.

rfc7540 doesn't seem to adress what should be the error condition when
the priority flag is enabled but the payload is smaller than what could
contain the priority bits. Seeing as a HEADERS frame changes connection
state I assume closing down via PROTOCOL_ERROR is the proper handling.

Fixes: #2349

The use case are cluster requests: Intra-cluster bgfetches should
trigger a synchronous fetch on the peer-varnish in order to avoid
additional short-lived / expired objects being created. Or, in
other words, a bgfetch should actually get a fresh object and not
one in grace from another cache.

Merges #2376

Merges #2381

Fixes #2380.

Fixes #2377.

This fixes a denial of service attack vector where bogusly large chunk
sizes in requests could be used to force restarts of the Varnish
server.

This is Varnish Security Vulnerability VSV00001

For more information visit: https://varnish-cache.org/security/VSV00001

Fixes: #2379

The previous code allowed the compiler to re-read nxt from
rr->nxt which could have been incremented cocurrently.

Fixes #2378

Part of #2344.

Related to #2337 and #2366.

Refs #1899

Closes: #2357

Probes currently running on a worker thread at the time they are
deleted will delay the release of the refcount they hold on the TCP
pool. Since this call will not be from the CLI thread we need locking
to protect these datastructures.

Fixes #2359