The error may be status 500 on 32-bit systems.

On the various platforms, esp 32-bit, workspace may be exhausted
before it gets to the VMOD at all, so we can't reliably expect
specific error messages.

This has nevertheless improved GCOV coverage, which was the goal.

To get some better GCOV coverage. So far just IDENTITY encoding.

This reverts commit 0139f83c.

Despite its obsolete purpose in the previous life of the VMOD, we
include config.h in all C sources for consistent configuration.

Had been used in its previous life as a 3rd-party VMOD.

Submitted by:	Frederic Lecaille <flecaille@haproxy.com>

Closes #2722

I've been torturing varnish with this change for some time and was
not able to reproduce the problem.

Should fix #2719.

Fixes	2727

Unless -1 is used too, but -1 already implies -d so it doesn't really
count.

Fixes #2721

This reverts commit d1b78e8d.

The problem is that upon exiting the screen is likely to be cleared on
most terminals (not the one we embed in varnishtest for example) so it
doesn't give any chance to the user to read the output.

The consensus is to restore the previous behavior and fix the manual
instead.

Conflicts:
	bin/varnishtest/tests/u00004.vtc
	bin/varnishtop/varnishtop.c

Breaks:
	bin/varnishtest/tests/r02686.vtc

Refs #2721

For some strange reason this is failing with 3.6 in travis.

This was the original intent but got lost in autoconf translation.

Fixes: #2572

with varnish user etc.

With the req.grace reintroduction, we got two identical cases where
we insert a busy object: When there is no exp_oc (obviously) or
when the exp_oc does not fulfil the req.grace limit. This lead
to some code duplication.

IMHO, handling first the case where we need to insert a busy object
(with or without exp_oc) and then handling the exception that we
do not wait on a busy object if the exp_oc is in grace is cleaner.

Please note that comparing this change using diff -u does not
make much sense, I believe the simplicity of the reshuffling
change becomes clear when looking at the old and new code side-by-side

The main point is to clearly recomend using req.grace for the most
common use case - using different grace time when the backend is
healthy.

Right now there are use cases that cannot be solved without req.ttl,
so we undeprecate it.

The req.grace variable can be set in vcl_recv to cap the grace
of objects in the cache, in the same way as in 3.0.x

The "keep" behavior changes with this patch. We now always go
to vcl_miss when the expired object is out of grace, or we go
to the waiting list. The result is that it is no longer
possible to deliver a "keep" object in vcl_hit.

Note that when we get to vcl_miss, we will still have the 304
candidate, but without the detour by vcl_hit.

This commit changes VCL, but only slightly, so we aim to back
port this to earlier versions of Varnish Cache.

Refs: #1799 and #2519

address family is neither of AF_INET or AF_INET6.

This means that UNKNOWN is sent in probes to UDS backends when
.proxy_header=1 is set.

Also verify that a UDS backend receives PROXY LOCAL in a probe when
.proxy_header=2 is set.

Fixes #2702
Closes #2726

Since we verify that header blocks are not interleaved, and we zero the
struct h2h_decode on every new header block, there is no need to malloc
a separate struct h2h_decode per stream.

For (real) backends, we used to assign the probe after adding the
director via VRT_AddDirector(). For an already warm vcl, this lead to
a VCL_WARM event missed because the event was issued by
VRT_AddDirector() when the probe did not exist yet.

We fix this by preparing all of the backend before adding the
director, undoing the work for a failure doing do.

In addition, if adding a backend while the vcl is cold, we need to set
the initial director state based on the probe configuration after
adding the director.

We avoid the overhead of the vcl temperature lock because no harm is
done: If, after the director was added, the temperature goes cold, we
just run an additional update, and if it goes warm, the update will
already have happened.

Likely related to https://github.com/nigoroll/libvmod-dynamic/issues/35

... to make the next commit more readable

To get out of a catch-22, see second next commit

... not in the caller

Future-proofing to avoid mistakenly introducing another race down the
line.

The current flow control code's use of h2->cond is racy.

h2->cond is already used for handing over a DATA frame to a stream
thread. In the event that we have both streams waiting on this condvar
for window updates and at the same time the rxthread gets signaled for a
DATA frame, we could end up waking up the wrong thread and the rxthread
gets stuck forever.

This commit addresses this by using a separate condvar for window
updates.

An alternative would be to always issue a broadcast on h2->cond instead
of signal, but I found this approach much cleaner.

Probably fixes: #2623

Turn the director destruction inside-out: When the vmod object goes
out of scope, we inform VRT that the director is to be
destroyed. Actual destruction is moved to the respective director
callback.

This allows directors to outlast vmod objects.

For vdir based directors, the director object is the vmod object; for
shard, the two are different instances (we might want to reconsider
changing this later).

Prepare for use of the shard director as a dynamic backend, where the
VCL_BACKEND can outlast the vmod object:

* the director priv now points to the struct sharddir instead of
  the vmod object

* move the default parameters pointer to struct sharddir

* index the PRIV_TASK by the struct sharddir pointer