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.

see vwe_enter

in particular

* VCL language and other literals as ``literal``
* placeholders and emphasis as *emphasis*
* no `interpreted text` except where it actually *is* that

Ref http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#character-level-inline-markup

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.