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

When a session has data pipelined we perform a dirty dance to move it at
the beginning of the workspace. The rollbacks used to occur between
HTC_RxPipeline() and HTC_RxInit() calls until it was centralized in the
latter.

With a dedicated WS_ReqPipeline() operation we can capture the semantics
of initializing an existing connection for its next task with or without
data fetched from the previous task.

While conceptually there is still a use-after-free since the pipelined
data may belong to the same workspace, it is fine if that happens within
the bounds of an atomic workspace operation.

When we take on a new request on a connection from which something was
already received, we need to pipeline it and we do so at the beginning
of the request workspace. There's a high probability that the pipeline
is coming from the same workspace, which is a form of use-after-free
only made safe by the workspace implementation details.

To avoid the conceptual use-after-free, we defer req workspace rollbacks
and perform them during the next HTC_RxInit() call before the pipelining
operation.

Because HTTP/1 works directly on the session, a worker can safely switch
back and forth between sess and req tasks. This means that unless the
session goes idle the same workspace is used from one client request
to the next, hence the rollback previously happening in Req_Cleanup().

With h2 however there is a disconnect between the session and streams.
The connection is received in req0's workspace, and then copied into
a stream's req workspace via the pipelining scheme. Rollbacks can be
deferred as well, but they need to happen otherwise the session will
soon overflow. Independent HTC_RxInit() calls happen for req0 in the
h2 session thread, and for h2 streams in the regular request task code
path.

PROXY Protocol parsing may result in receiving more than the proxy
preamble itself and pipelining will happen, whether it is via a req
for HTTP/1 or req0 for h2.

On the other end of the spectrum when Varnish acts as a client it
only sends one HTTP/1 request at a time for a given connection, so
we never expect pipelining to occur in fetch task.

Some of the autoconf logic is originally from Asad. In addition, the
explicit call to __gcov_flush() is now vendored in vdef.h like other
toolchain abstractions.

Similarly to how the ASAN setup was split in two steps.

Spotted this unusual construct while sweeping through the sanitizer flags.

Instead of referring to them for every single binary we build... While
at it we shouldn't need to add -fsanitize=stuff to LDFLAGS, and we
didn't in some cases. That should lead to smaller lines when running
make with V=1 or when silent rules are disabled.

To avoid repetition and very long lines.

Removing unused *SAN_*FLAGS variables and making sure to quote anything
that may be relevant to quote. Hopefully indenting in more readable way.

Fixes: #3634

Previously we would read the response Content-Length from a failed oc,
which would make the error response valid. Now, if this is detected,
we don't touch the Content-Length.

With the synth->filters koncept out of the picture this becomes
possible.

Fixes: #3441

Closes: #3318

Renovate `-n` and `-a` manual page descriptions

Fixes: #3672

After the removal of VSB_new() and VSB_delete().

Refs 5884e2f2

This will hopefully silence our continuous integration complaining way
too often about server leaking what http_process_cleanup() should take
care of.

The nested while loop made more sense when the surroundings were more
complicated.

Better diff with the --ignore-all-space option.