Comparing a backend with various stuff was not handled well. The test
case shows what will give a compilation error, and the results of ways
of comparing backends. When using a director, the demonstrated results
are not obvious.

Fixes: #2168

Fixes: #2178

This reverts commit 95100cd0.

We already had a check that took care of this in an architecture
independent way.

See 452ac521
Closes #1750

There was an error in the last changelog update.

When going on a waitinglist, the HTTP1 step counter was set to
S_STP_H1BUSY to allow conditions to be checked on return specific to
having been on a waitinglist. Though the step counter was set after
entering the waitinglist, and if the session was rescheduled
immediately on another thread a race opened which would mess up the
state handling.

Fix this by elliminating the S_STP_H1BUSY step, and having condition
checks on req->hash_objhead in the S_STP_H1PROC state to handle the
waitinglist return specific checks.

The panic output has been changed to include the req->hash_objhead
pointer if set. This exposes the waitinglist condition in the panic
output which would otherwise be hidden by the removal of the
S_STP_H1BUSY step.

Fixes: #2117

Closes #1750

Fixes #2134.

The previous commit was not a good backport, as I did not check the
new test case. Now the test case has been updated, and everything
should work.

Fixes #2148.

Increase the Nagle-avoidance delay in r02035.vtc to make the test case
less timing sensitive.

HTC_RxInit and HTC_RxReInit could write a single '\0' NUL character
outside of the workspace when its called and there is zero bytes left
in the workspace. This would trigger the workspace canary causing
subsequent assertion.

Fix by releaving HTC_RxInit and HTC_RxReInit of adding the '\0'
character.

HTC_RxStuff and V1F_FetchRespHdr returns HTC_S_OVERFLOW if the
available buffer space is zero. Both make sure to insert the '\0'
character just before calling the completion check function.

Note that this fix does not change the fact that we have exchausted
the workspace and are unable to continue. Varnishd will panic
nonetheless, but at least we have not stepped out of our boundries.

Ref: #1834

Make sure that the workspace can accomodate the pipelined data before
memmoving it into place in SES_RxReInit.

When doing range delivery, make the delivery processing finish early
when all of the bytes of the requested range has been delivered. This
to avoid waiting around for a slow fetch to finish before handling the
next request on the connection.

Fixes: #2035

A delivery processor may want to finish the delivery early. Change the
return value from VDP_bytes and the delivery processors into 3
categories. 0 means continue, negative is error and positive is
finished.

The latching of errors (to help ESI delivery continue while still
recording the error) will latch the lowest non-zero value observed.

VDP_gunzip is fixed to not unconditionally return errors.

Also add some text to explain the behaviour of VDP_bytes and its
delivery processors.

(backend tasks for the time being)

Add parameter thread_pool_reserve to tweak

Conflicts:
	bin/varnishd/mgt/mgt_pool.c

We should queue bo tasks to avoid failing client requests
unnecessarily.

The detailed parameter description of the queue_limit was already
correct, improve the short one.

The nthr => wthread_min assertion could trigger if
wthread_min was changed after the first comparison.

Previously, after sending a thread to varnish heaven, the herder slept
for wthread_destroy_delay unconditionally. Instead, we now wait on the
cv so we get woken up in case we run dry during the delay.

This change is relevant proportionally to the value of
wthread_destroy_delay if the spread between thread_pool_min and
thread_pool_max is big and varnish is exposed to sudden traffic peaks.

IOW, it will probably be only relevant for high performance setups.

Also, we now sleep for thread_pool_timeout unless a shorter delay is
warranted. This will delay the effect of thread parameter changes for
up to thread_pool_timeout seconds unless the pool runs dry, in which
case they will become effective immediately.

doc-fixes #2129

For epoll, we tolerate spurious reports, for all other waiters
we assert.

fixes #2117

Conflicts:
	bin/varnishd/waiter/cache_waiter_epoll.c

Fixes #1899
Closes #2110

Ramp up from simple tokens to here documents.

Conflicts:
	doc/sphinx/reference/varnish-cli.rst

When checking the timestamps on deleting a session, allow up to
clock_step seconds error before bailing.

Fixes: #1874

This value is used in calculations that could reveal clock step,
specifying the amount of error we allow before panicking. It defaults
to a conservative 1 second.

Show both the real and the monotonic time in the panic output when the
panic is created. This is useful to have something to compare other
panic timestamps against.

The existing timestamp in the panic output is recorded by the
management process at the time of receiving the panic from the child
process. Due to processing and possible core dump creation, this time
isn't very useful for comparison purposes.

Spotted & prodded by: 	Hermunn
Closes: #2026

Use MGT_complain() to log any errors; we might have a better chance to
understand what's going in.

Fixes #2115.

When we renamed resp.msg to resp.reason to match RFC and VCL terminology
we forgot to rename its counterpart. Instead of renaming -msg to -reason
the former will instead become an alias of the latter. This way it can
be applied to older branches (modulus inline documentation).

(Backport of 2bbcde1d with the fix b698aec2 squashed in)

doc fixes #2107

Updated error message in MGT_Child_Cli_Fail to indicate that we
actually have sent the kill signal to the child process.