Ref 31164908

Fixes #3243

we do want to use FLAGX | FLAGY even if zero for clarity

error:

Info 835: A zero has been given as right argument to operator '|'

Another case of struct instance names which we want to have, even though
we do not currently use them.

Yes, we do not actually use the mode name, but we still want to have it
for debugging and clarity.

Info 754: local struct member 'vsc_sf_mode::name' (line 57, file
    ../../lib/libvarnishapi/vsc.c) not referenced

Fixes #3243

We want to avoid unsigned integers for reference counting since they
would hide underflows.

Seeing a test failure on vtest I think there might be a race here that I
hope to make more explicit next time it occurs.

A nice and tidy single token to integrate with the parameters table.

Refs #3250

This reverts commit 5367be3f.

polish differently and more sensibly

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.