This still lacks error handling and thus is not a fix for #2589, but at
least we're not writing past the end of the workspace any more.

header lines.

Fixes:	#2678

Fixes: #2682

after the headers.

Fixes: #2731

Start pylinting while here anyway.

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

Closes: #2737

Fixes: #2729

counting deck-chairs on the Titanic.

client content -> client context

this tests d912ffe4

Tweaked:
	bin/varnishtest/tests/d00007.vtc

In 6.0 this bug doesn't exist and directors behave slightly differently
so the test case needed some adjustments to both show that a backend can
be added to an already warm VCL with a probe, and that requests succeed.

This was a proof of concept for an alternative WS interface -- write
incrementally to reserved workspace as an "open buffer".

That may be generally useful for Varnish, but for now we return to
the usual WS_* idiom.

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.

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

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