and change the t0 argument into a vtim_real deadline, allowing for
adjustments per call.

This causes changes of send_timeout to not change open V1L transactions.

This also exposed the fact that we are using send_timeout also for
sending the bereq.body to the backend. Is this what we want?

timevals and timespecs could represent vtim_real / vmtim_mono
also, but for now, all use cases within varnish-cache are for vtim_dur

As we typedef vtim_{real,mono,dur} to double at the moment, this should
not break any vmods.

The trick here is that these tests depend on c1 getting in front of
c2... and that cannot be assumed given random thread scheduling algorithms,
it must be enforced with barriers

(i hope)

Trouble here is that in pool_herder(), we access pp->dry unprotected, so
we might see an old value, thus we might breed more than wthread_min
even if the dry condition does not exist any more.

So for the vtc, we need to wait until wthread_timeout has passed and the
surplus thread has been kissed to death.

Notice that this does not change with #2942 because there the same
unprotected access happens to lqueue.

This reverts commit fa3e1419.

We might have over-bread such that thread_pool_timeout becomes relevant
at the other place in pool_herder()

it should remove the worker it returns from the idle queue for clarity

the herder delay to .5 seconds anyway

This reverts commit 3e6e584b.

No use, still happens

It seems that these test cases were suffering under the problem that #2942
addresses. Set a minimum thread pool so that there will be adequate
threads available before the test begins.

I ignored this for ages, but now it really bothers me: This test had
quite a high failure rate on systems I control. And actually I do not
quite understand why the fix works, but it does survive -j100 -n1000

Additional input welcome

includes vtc

Purposes:

* Allow to optimize keepalive for trusted client connections (e.g. CDN,
  authenticated clients)

* Prepare for an optimization to time out connections on inactive VCLs
  earlier (see #2764)

Other client timeouts will be added when accepted.

Fixes #2949

This rushes the waitinglist when encountering a hit-for-pass during
HSH_Lookup. Without this, the rushing may be delayed until the passed
object completes delivery.

Test cases c00098.vtc and c00099.vtc tests this early rushing behaviour
for HFP and HFM respectively.

Fixes: #2978

This makes waitinglist rushes happen also in HSH_Lookup when encountering
cache hits. This helps to get the requests on the waitinglist restarted
when doing streaming delivery.

Fixes: #2977

their VCL from going cold.

One half of #2471

which nobody else is allowed to even think about calling.

ca-certificates is already installed so for now just ignore any ssl
errors.

Hopefully this will fix the error with coverity.

the pointer indirection would make sense if we had any long lived struct
waited instances so the timeout parameter could change. But we don't.

Also the vtim_ type was wrong, it is a duration.

Via lgtm.

exotic compilers complain about incomplete type

It had been iterating through the vfps list, as VCL_StackVFP does,
rather than the vdps.

Add a test for a VMOD-defined VDP.