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.

Update the code to accommodate this.  Originally reported by Reinis
Rozitis (r at roze.lv) on varnish-misc.

Fixes #2118.

We need to veirfy this apparently innocuous change does not have any
side effects.

this reflects changes from 5b2888f3 and
a3b06bb2

Spotted & prodded by: 	Hermunn
Closes: #2026

This is in preparation for upcoming changes.

This tells Varnish which storage backend it should use when dealing with
the request body (if any).

Fixes #1914.

This supersedes beresp.storage_hint but is kept around for backward
compatibility until the next major release.

Setting beresp.storage_hint to a valid storage will set beresp.storage
as well. If the storage is invalid, beresp.storage is left untouched.

This also reworks how the storage selection is done when multiple
storages are defined but none is explicitly set, and what nuke limit we
use. Previously we will first try with a nuke limit of 0, and on failure
retry with the configured nuke limit. Furthermore, if we did not specify
the storage we will go through every one in RR fashion with a nuke limit
of 0 before retrying.

With this change we initialise beresp.storage with a storage backend from
the list before we enter v_b_r{}. At the end of v_b_r{} we will use
whatever storage is in beresp.storage. If the storage is NULL we fail
the request. In all cases we use the nuke limit.

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 termonology
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).

vmodtool already includes the copyright from the boilerplate

Authors and contributors are numerous, so we'd either need to name
them all or none.

otherwise, when the tests directory contains vtc files whose names
get sorted differently in the current environment's locale than in C,
config.status will get re-run for every make check invocation, which
is particularly annoying with parallel makes

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

A new jail level, JAIL_MASTER_KILL, is introduced. The mgt process
takes this level before killing the child process.

Fixes: #2010

A new function, kill_child() is introduced, so that kill() is only
called from this function. This is a preparation of fixing the jail
implementation.

There seems to be an error in the varnish jail design, which makes the
mgt process uable to kill the child process. To confirm this, add some
error checking to the relevant code.

Related to: #2010