This fixes #3003 properly

restore tests/r02219.vtc to the same headroom as before

we need additional workspace for the priv_top which now always gets
initialized (32 bytes on my machine)

Also fix some errors in vcl0 handling:

- Only the top request may release vcl0 because it owns it
- because we can re-embark for ESI, we can not assert that vcl0 is NULL
  in CNT_Embark()

passes tests/r02849.vtc again.

still fails r03003.vtc, which will get fixed in a follow up commit

Fixes #3019 with test case by @Dridi

Dynamically creating it through Req_MakeTop() would further complicate
rollbacks.

The memory overhead is basically identical to embedding struct reqtop
into struct req, except that, for ESI, we have the (struct req).top
point to the top request's struct reqtop.

With this commit, tests/r02849.vtc and tests/r03003.vtc are failing as
excpected. While this may impose issues with git bisect, I still think
that this extra commit helps clarity.

This reverts commit d6799345.

We will use struct reqtop for vcl0 and PRIV_TOP in follow-up commits.

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.