constify and avoid (char *) = strchr((const char *), x)

error:

vtc_varnish.c  559  Error 158: Assignment to variable 'la' (line 548)
increases capability

as copies of the respective client side flags

When a parameter set is associated at the director level, it should be
in effect with resolve=NOW as with resolve=LAZY.

This adds VTCP_Assert() on the result of read and write calls that deals
with TCP sockets.

When used to check the result of read() and write() calls, it is useful
that a positive return value is accepted in VTCP_Check().

Now that VTCP_Assert() accepts EAGAIN as a legal errno value for read()
errors, uncomment this check.

Since the input value is sometimes the result of a read()/write() call,
avoid truncating the ssize_t value on calling it.

When a socket timeout is set on a socket and the timeout expires, read()
and write() calls on that socket will return (-1) with errno set to
EAGAIN/EWOULDBLOCK.

Consistently use VTCP_Assert when asserting on the result of VTCP_Check().

for VCL_* functions from cache_varnishd.h

Ref: 1e09f422

I find ":path: /foo" more descriptive than "/foo", even though I could
infer which one it was...

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.