Until now, more or less the only option to copy data from the VCL
client side to the backend side is through headers, as `bereq.http` is
initialized as a copy of `req.http` (additions to this are the
recently changed `client.identity` and `req.backend_hint`).

We now add the option for vmods to register a callback per `PRIV_TASK`
which can then be used to copy vmod owned data from the client to the
backend side.

Callback registrations are kept on a list hanging off `struct req` on
demand. When a backend request is created, the registered functions
are called in order of registration.

The base memory cost to this is one pointer added to `struct req`. If
no registrations are used, this is the only impact on memory
requirements.
The runtime overhead when no callbacks are registered is close to a
noop: one function call to `vbf_privs_copy()`, which only checks a
pointer (besides the common `CHECK_OBJ_*` argument checks).

Alternatives considered:

A straight forward alternative would be a per `PRIV_TASK` copy
function pointer paralleling the free pointer. This option would
charge every `PRIV_TASK` with an additional pointer. Under the
assumption that `PRIV_TASK` copy operations will be required for
select data only, this option was dismissed. It should be noted though
that this option could be more memory efficient if a relevant
proportion of `PRIV_TASKs` requested copying (one pointer vs. approx 4
pointers for this solution).

Another option was to add an event signalled to vmods for backend
request creation (basically `STP_MKBEREQ`). This would allow for the
same functionality as proposed here, but vmods would be responsible to
track all `PRIV_TASK`s requiring copying themsevles. This tracking
would be similar to what is suggested herein, but without the reuse.

In the next commit we are going to need a lookup which does not create
privs.

Long story short: newer coreutils use `statx` which isn't supported by
old kernel, so the `debian:bullseye` images blew up.

Similarly to Timestamp:Fetch, it is otherwise not possible to distinguish
between time spent in VCL and time spent strictly fetching the response
body.

If significant time is passed in vcl_backend_fetch it becomes difficult
to interpret Timestamp:Connected, which this new timestamp remedies.

Depending on the settings, a timeout can be ambiguous. It's also
generally useful to be able to tell how long it takes, monitor it
and possibly notice a degradation before errors start manifesting
themselves.

it is too far down the stack.  Instead pass the objcore through
the priv structure from ved_deliver() which has legitimate access.

complement the existing c88 test with changing the path of a backend.

They are taking too long, needlessly holding onto job slots forever.

Align with CircleCI for now, even though we could probably do more.

Except those present in varnishtest/vtest.

Spotted on CircleCI:

    ---- v1    Not true: MAIN.threads (26) == 10 (10)

Refs #2942

When a test case successfully runs this:

    varnish v1 -start

The following macros are created:

- ${v1_addr}
- ${v1_port}
- ${v1_sock}

When v1 listens to a UNIX domain socket, those macros become useless and
we generally have to repeat the socket path wherever we need it.

From now on, varnish listen address macros for unix domain sockets match
their server counterparts:

- ${v1_addr} expands to "0.0.0.0"
- ${v1_port} expands to "0"
- ${v1_sock} expands to the socket path

It is now possible to use the following construct regardless of the
socket type:

    client c1 -connect "${v1_sock}"

In addition, the debug.listen_address command now outputs the listen
address name in addition to its endpoint. For example, in a test case
with the following command:

    varnish v1 -arg "-a :0 -a :0 -b '${bad_backend}'" -start

The output for debug.listen_address could look like this:

    a0 127.0.0.1 34567
    a0 ::1 34567
    a1 127.0.0.1 45678
    a1 ::1 45678

The resulting macros would be:

- ${v1_addr}
- ${v1_port}
- ${v1_sock}
- ${v1_a0_addr}
- ${v1_a0_port}
- ${v1_a0_sock}
- ${v1_a1_addr}
- ${v1_a1_port}
- ${v1_a1_sock}

It becomes possible to reliably listen to multiple endpoints and use
either in a test case. On a dual-stack system where we might end up
with multiple endpoints sharing the same name, only the first one is
used for a given name. In the example above all macros would expand
to IPv4 addresses.

We can't start linking files from $(srcdir) to $(builddir) until we are
done populating files in $(builddir). Make sure we defer linking until
after all sphinx sources are ready.

This reverts commit 89a558e5.

I also added a note to avoid falling in the same trap again.

The net result is the same, but should be more readable.

Better diff with the --word-diff --word-diff-regex=. options.