This reverts commit d6d34160 which
reverted 86af5ce0.

The regression documented in #3003 will be solved differently in
follow-up commits.

r03003.vtc added in d6d34160 is kept

I noticed that the stream 0 header accounting changes with len == 0 VDP
bytes, which seems useless.

Fix the probe scheduler heap comparison function to be consistent with
regard to different running state of the two arguments. With this fix,
probes that are not running will always bubble to the top before those
that are already running.

closes #3118

The VCL compilation error message when a VMOD symbol does not exist
simply disappeared. When I figured how to bring it back I was lucky
my test case exhibited another quirk for the following case:

    new foo = bar.foo()

Where bar is a successfully imported VMOD, and foo is the missing
constructor. For some reason instance symbols are created with VCL
low and high values, so the missing foo constructor ended up being
confused with the existing foo instance.

The regression I initially hunted down (the lack of error message
in the first place) was introduced by 340abd04. I suggest we
don't give VMOD-induced symbols a VCL low/high since by definition
they are not tied to a VCL version (even though they may do so at
run time) and use that criteria to filter out the spurious error
message:

> Symbol not found: 'directors.foo' (Only available when 4.0 <= VCL
> syntax <= 4.0)

If there is no proper low or high (and 4.0 is legit) then we don't
print the "Only available when" part? For now I needed the bandaid.

Refs 340abd04

We have a new printf_nofmt.cocci semantic patch to catch future
offenders.

not buy us anything because the compiler can see at all times what
goes on.

Spotted via vtest.

now that we pass the bo's handling to the director method, in the case
of return(error) from v_b_f, we do no not want the deliberate
VDI_Finish() to change the handling from vcl.

Tests #2997

This is another requirement for use of VRT_fail() in director context.

For code checking for (struct vrt_ctx *)->vsl the logging order now may
change, and we might want to review our VSL() calls if the ctx vsl
buffer may now be used instead.

Ref #2997

This is option 'always add ctx->handling' from #2997:

we add the (struct vrt_ctx).handling pointer even where there is no VCL
method for consistency to enable use of VRT_fail() consistently.

When making other changes which require additional workspace, this test
may fail for too big a request in the first place.

This additional logging facilitates before/after analysis

we should not emit ReqUnset / ReqHeader if A-E is already correct

This was meant to go to a different remote before proposing it.
Sorry!

unmask/mask was inverted

remove superfluous comma

Fixes #3110

from both client and backend side.

When we breed threads without a delay, we should make an effort to let
them run as soon as possible and not have the cpu occupied with the
herder code.

This will increase the overhead due to additional context switching for
the benefit of reducing latencies until new threads get to run.

Effect seen with this vtc by @Dridi:

    varnishtest "over-breeding"

    varnish v1 -arg "-p thread_pools=1 -p thread_pool_min=10"
    varnish v1 -vcl {
            backend be none;
    } -start

    varnish v1 -expect MAIN.threads == 10

Tested with the following script:

    ./varnishtest -i -k -j40 -n1000 tests/as_above.vtc |
    awk '/^#/ { print $5; }'|
    sort |
    uniq -c

Multiple runs show a consistent drop of failed tests:

    before | after
    -------+------
        76 |    18
        67 |    24
        66 |    18

Fixes #3045