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.

We're missing the ability to easily pass some extra debugging options,
typically memory poisonning or memory limitations, while executing tests.
Let's add the consideration for the HAPROXY_ARGS environment variable, to
optionally prepend a series of arguments.

Will apply the specific vtest patch instead

This reverts commit cf7304c6.

which does not depend on ipv4/ipv6

from c862d49e

it does not understand that wrk_addstat() only returns true for tp !=
NULL.

the "who" parameter was intended for error reporting, but we never used
it. And now that vmod_shard_param_read() cannot fail, we are sure we
never will.

Now that we do not make allocations for reading parameters, we can
assert that we always have them.

We only need a new priv_task if we need to log an error.

If one existed before, we need to clear or overwrite the error.

It's a bit dirty because one code paths comes locked while the other one
has the pool unlocked, but this removes the need to duplicate conditions.

The pool_addstat() function was unrolled to its single call site.

When a session is continuously used, for example in a multi-tier setup,
it can take a very long time before an HTTP/1 session runs out of tasks
and unwinds back to the point where the worker might update its stats.

This phenomenon is amplified by thread_stats_rate, so it might take even
longer to get statistics published. This is famously observed with load
testing campaigns where a certain set of VSCs may not increase at all
until the very end of a load run.

This change makes it possible for HTTP/1 sessions to at least publish
their statistics into the pool every thread_stats_rate requests.

To avoid a potential performance cost, this behavior (technically
complying with the documentation) is guarded by a feature flag. The
flag is generic so this behavior may be extended to other busy loops,
present (if any) or future.

When gauges are incremented and decremented by different threads, there
is a chance that decrements are published first, provoking an underflow
of the VSC. Values with the MSB set are considered underflowed, adjusted
to zero instead.

If the DBG_VCLREL is in effect and there are unpushed pool stats, make
sure that some thread is waking up to perform the late push. This should
help with stability for VTC test cases using the DBG_VCLREL flag.

Often in test cases the siutation comes where multiple threads go idle at
the same time, and no new activity happens after that. This would
potentially create the situation where the last thread to go idle sees
that some thread is currently pushing stats to global, so it leaves its
stats contribution on the pool stats to avoid contention. But without new
activity in the future, the pool stats may stay in the pool accumulator
indefinitely.

This patch adds a check to see if there are unaccumulated statistics
lingering in the pool accumulator when a thread wakes after idling to
release its VCL reference. If there are, the thread takes on the task of
pushing the pool stats to the global stats. This should help with test
case stability, and potentially help with underflowed stats reported by
some users.

For a red-black tree insert in vrt_priv_dynamic(), we performed a lookup
and then an insert, resulting in basically the same tree traversal
twice.

We now prepare a new struct vrt_priv on the workspace and release it if
the respective priv already existed on the tree.

For a full workspace, we fall back to a lookup via
vrt_priv_dynamic_get().

polishes 06cf60a0

I should have taken more time for that merge.

just to clarify for the next commit.

VRT_priv_task() inserts a priv_task if it does not exist.

In some cases, it is more efficient to only insert a priv_task under
certain conditions. These require an API function to only return a
priv_task if it exists. This is VRT_priv_task_lookup().

A TODO comment has been added for a sensible performance optimization,
avoiding one VRBT traversal for the VRT_priv_task() case. I would
address this after this suggestion got accepted, if so.

as suggested by Dridi

Originally suggested by @rezan in
https://github.com/varnishcache/varnish-cache/pull/3408/commits/4caad2c1858afb399f75230916183d31f57fc908