Relying on fixed vxids was found to fail, sorry

see comment in the vtc: For now this test is exploiting some
implementation detail and we might want to consider adding a VSL for
waiter involvement.

Ref #2980

should also fix printf format errors on 32bit

the last uses were removed in fcbc7951

It is unclear to me whether those calls belong under the h2 session
lock, but this patch doesn't change any behavior.

The dummy_acct is only here to avoid repeating null checks in the send
loop below. This doesn't change the end result if the transaction
completes with no problem. As such, only header and body bytes are
accounted for, as before, ignoring h2 framing overhead and in general
other kinds of frames that belong to the stream.

In other words, the only improvement is that ReqAcct doesn't show a full
delivery when the client hangs up before the end of the transaction.

The split of H2_Send will allow handling of error conditions from the
multiple return statements although at this point there is no change in
this area.

And make it clear that we steal the reference at this point.

For now the varnishd handling of SO_SNDBUF lives in vmod-debug but could
be promoted to vmod-vtc to be usable out of tree too.

hope we'll get to a better option soon.

Ref: 691d5ac9

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