This parameter allows the user to choose which storage backend / stevedore
that the H/2 receive buffers are allocated from. By default it uses
Transient.

This was found lacking in our H2 implementation. Previously we would have
included any padding bytes in the request body. Possibly it would have
caused errors if there also was a C-L present, or more likely just corrupt
request bodies.

If the client sends nothing but padding bytes and ends up consuming the
entire stream window with no actual request bytes buffered, the request
thread side of things would not send any stream window updates. Handle
this corner case by sending a window update from the session thread.

According to the spec the padding is an 8-bit field, and fields should be
treated as unsigned unless otherwise specified, which it is not for any of
the padding related places. Allow varnishtest to generate padding up to
255 bytes long.

This is the test case that fails if these changes aren't in tree. Note the
commented out rxwinup commands that are necessary for the proper fail mode
when run without the varnishtest window update changes.

With the new request body data handling, Varnish changes behaviour
significantly wrt to stream window updates sent to the client. Window
updates will only be sent once the data is consumed by the client through
the request body VFP handling. Test cases that rely on receiving a window
update to sync the H/2 stream needs to be adopted.

This makes it easier to not have to know exactly when and how many window
updates to expect in a test case.

We have a strict min at the protocol default here. This is because we
don't have the 'use settings only after peer ack' in place yet. If the
value is lower than the protocol default, the very first stream could get
a flow control error.

H2 streams waiting for request body data will timeout after timeout_idle
seconds if no new data on the stream is being received. This will ensure
that individual H2 streams can be reaped if there is no data received from
the peer.

This implements stream data handling using a buffer between the H/2
session thread and each stream thread. This is needed to avoid head of
line blocking on the session socket when a data frame is received for a
stream thread that is not yet ready to receive it.

The buffer used will have to be as large as the send window the peer
expects at the time the stream is opened. This will typically be 65535
unless the h2_initial_window_size parameter has been changed.

Stream window updates will then be issued only once data is removed from
the buffer by the request body being consumed from the request handling
thread, limited in size to what space is then available in the buffer.

The H/2 session thread does have a VSL buffer already set up, but the
'wrk->vsl' pointer was not set. This caused issue for e.g. LRU_NukeOne()
as it wants to log. Set the buffer for the duration that the worker is
dedicated as an H/2 session thread.

This is an API for getting an arbitrary buffer through the
stevedores. The stevedore in question may then deploy LRU nuking or other
measures to control resource usage.

Working on the workspace sanitizer (ancestor of the workspace emulator)
final rollbacks were needed to unwind allocations. There was however a
branch where error handling was missing a workspace release, and it was
fine before the introduction of the final rollbacks.

To avoid turning the workspace emulator into a DoS vector the rollbacks
are now only enforced for emulator builds. The specific "insufficient
workspace" log is amended to ensure future changes to the session
workspace footprint don't accidentally remove test coverage for that
branch. The same could be done for other "insufficient workspace" logs
in the PROXY protocol parsing.

Refs 0632b846 (req: Prevent early rollback)
Refs ce71896a (sess: Plug conceptual leak)
Refs 246b1eb1 (busyobj: Plug conceptual leak)
Refs 5b4f0f1a (htc: Defer workspace rollbacks for request tasks)
Refs #3644

Spotted by Alf's single process fuzzing setup that we should eventually
revisit.

Refs #3152

Most of this is taken from #3650 but instead of `str[n]casecmp`
it uses VCT functionality, in order to avoid LOCALE poisoning.

Closes #3650

Fixes #3677

Otherwise we would entirely unravel the task workspace.

The goal of the workspace emulator is to replicate the regular workspace
behavior with individual allocations and make it work transparently.

It's the successor of the workspace sanitizer from #3320 with notable
differences:

- enabled at configure time instead of run time
- in a separate source file instead of mixed in
- using sparse allocations instead of built-in red zones

This means that the workspace emulator can be combined with regular
sanitizer, in particular asan and lsan. If available, asan's public
interface is used to mitigate the possible overflow of a reservation
after some of it was released.

Even without sanitizers, the fact that we integrate with jemalloc by
default and enable its abort and junk options in varnishtest is enough
to detect a use-after-free in some cases.

With sanitizers though, the workspace emulator can observe #3550.

One drawback is that the logic is split in two files, and some functions
are identical in the two files. It might be possible to split cache_ws.c
into something like cache_ws_alloc.c and cache_ws_util.c for example.

Closes #3320
Refs #3550
Refs #3600