FlexeLint is getting its knickers in a twist about.

special treatment.

(backend tasks for the time being)

Add parameter thread_pool_reserve to tweak

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.

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.