Is it because German capitalizes so many words that his shift keys have
become hit or miss?

as suggested by @Dridi with reference to @bsdphk in
https://github.com/varnishcache/varnish-cache/pull/3130#pullrequestreview-316916213

we ensure that only backends on the director_list receive events.
Because events happen in the cli thread, we do not need another level of
serialization.

There is no explicit vtc, the test case has been added to vmod_debug and
runs with every invocation of that vmod.

Fixes #3094

we are going to need to check a temperature on its own

Ref #3094

Fix a small memory leak when failing to spawn a new thread.

When getidleworker signals the pool herder to spawn a thread, it increases
the dry counter, and the herder resets dry again when spawning a single
thread. This will in many cases only create a single thread even though
the herder was signaled dry multiple times, and may cause a situation
where the cache acceptor is queued and no new thread is created. Together
with long lasting tasks (ie endless pipelines), and all other tasks having
higher priority, this will prevent the cache acceptor from being
rescheduled.

c00096.vtc demonstrates how this can lock up.

To fix this, spawn threads if we have queued tasks and we are below the
thread maximum level.

Fixed the typos in the files mentioned in the corresponding issue.

Fixes #3135

Otherwise you might run into this:

    Message from VCC-compiler:
    Unused backend nil, defined:
    ('<vcl.inline>' Line 4 Pos 17)
            backend nil none;
    ----------------###------

    (That was just a warning)
    Message from C-compiler:
    vgc.c:1476:20: error: unused variable 'vgc_backend_nil' [-Werror,-Wunused-variable]
    static VCL_BACKEND vgc_backend_nil;
                       ^
    1 error generated.
    Running C-compiler failed, exited with 1
    VCL compilation failed

This is done in both init and discard code to maintain the balance.

This reverts commit 1d23a733.

Fixes #3131

Because someone brought a suncc to a vtest party.

Now that vtc.typesize() is a bit more reliable, it's easier to deal with
architecture differences for the sizeof struct vrt_blob. For a much more
reliable failure check, it now looks at logs.

There may also have been a time when depending on the error we trigger
we could fail with a 500 or a 503, this is no longer the case.

For the nitty-gritty of the new test case, there are some comments to
hopefully help (at least my future self) decipher this beast.

This new test case remains stable even with the changes from #3123.

And start adding some coverage, certainly not exhaustive.

added by @lkarsten as suggested by @Driri in #3122

This adds another vim-style key binding to varnishstat.

Couldn't find any good way to extend u00008.vtc to test it. The
cursor is always at column 22 and page-downing to the bottom
will break the test case when we add another counter.

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.