Based on anecdotal evidence that it is not often used, and the concern
of lock contention it might contribute to since such records are emitted
unbuffered for every single expiry event, it is now disabled by default.

ExpKill records are still available if needed for example for debugging
purposes, and are enabled in the 3 test cases where we use them. They
were also getting in the way of 1 test.

Closes #3475

I overlooked use of an uninialized mutex.

Fixes https://github.com/vtest/VTest/issues/26

Fix in next commit

This reverts commit f855fa46.

... where log order is undeterministic (I mean, not really, but from the
perspective of our tests it can not be determined).

These efforts lead nowhere. The problem needed to be solved at the root.

This reverts commit 05e79574.
This reverts commit b02c7843.

This was another great idea by Dridi, thank you!

We see cases in VSL where the order of some events can not be (is hard
to) fix. For these cases, we add "all of these have to match, but we do
not care about the order" semantics through "?" in the skip column of
"expect" lines.

Example:

        expect 0 =    Debug             1
        expect ? =    Debug             a
        expect ? =    Debug             b
        expect ? =    Debug             c
        expect 0 =    Debug             2

After a line has matched "1", lines matching a, b or c in any order must
follow and then a line matching "2".

In the log, an "alt" line is emitted whenever an alternative expect is
evaluated.

When an alternative matches, matching will continue with the same
"expect" as before.

Implementation:

The skip_max field of (struct logexp_test) was already used for LE_ANY
if not a non-negative integer.

We add LE_ALT and LE_SEEN. The former denotes an expect with
alternatives (that is, the instruction to look for alternatives after
this expect) and the latter denotes an LE_ALT that has been matched.
Obviously, LE_SEEN is internal and can not result from the logexpect
configuration.

When a match on an LE_ALT fails, we do not advance le->test, but rather
look forward in the expect list for any other altnertives and try them
until we either have a match or run out of alternatives.

pull out the match code

It might not make a difference, except for the disappearance of a magic
number.

This reverts commit 7e9c6a7b.

see previous, fix typo along the way

Ref d89c8bf5

this turned out to be harder than I thought: I had not considered the
fact that fini order of a red-black tree indexed by uintptrs depends on
the memory order.

Ref d89c8bf5

Ref d89c8bf5

Trying to be more descriptive about glob patterns, inspired by the
backend.list documentation.

Suggested by slink.

And assert that it is emptied after all vcl.discard commands.

Better diff with the --word-diff --word-diff-regex='\w+' options.

Using a single glob defeats the purpose of the previous check.

This replaces the previous mapping of VCLs to discard with a mark and
sweep operation where a different head is used to track matching VCLs.

To discard VCLs in topological order, we can simply discard dependencies
recursively before discarding a given VCL.

this is how we have been using VRT_priv_task() for long. Before making
it the official way, bring vmod_debug and our own tests in sync.

This tests

	- that PRIV_TASK is different for client and backend side
	- that vcl_pipe is client side wrt PRIV_TASK
	- that finalizers are called

and probably things I forgot.

Sorry, this was a stupid oversight. The worker thread gets already named
by wrk_bgthread

This reverts commit a19e2262.