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.

This reverts commit c8d8d187.

Refs #3250

The problem with NOT_IMPLEMENTED is that it's contextual, so we can't
reliably generate documentation that marks all conditional parameters
as such.

While at it, unsign the flags in parameter specs.

Slightly better diff with the --word-diff option.

Refs #3250

Refs #3250

Refs #3250

Unlike simple parameters, the field names in struct params don't match
the parameters names. To deal with that a new field is added to PARAM()
macros to allow simple and thread parameters to set themselves apart
in that regard without getting any more intrusive.

Refs #3250

Unlike string or VCC parameters they are inherited, but their definition
is not as straightforward as simple parameters. They also need to be
guarded by PARAM_ALL because inside struct params they are groupped in a
dedicated struct vre_limits, and there is no need for disruption in that
area.

Refs #3250

Just like string parameters, they need to be guarded by PARAM_ALL since
they are not inherited by the cache process.

Refs #3250

Following the model of simple parameters, it is possible to find a home
for string parameters in params.h too. A new PARAM_STRING() macro deals
with the specificities of such parameters.

Since string parameters are typically not inherited by the cache process
they are guarded by a PARAM_ALL macro that defines whether a subset or
the whole list of parameters is processed when params.h is #include'd.

Refs #3250

The simple parameters are those that successfully migrated to params.h
because they were trivial to declare in a way that could be used in all
the places where they are needed.

The PARAM() macro is now changed so that the outstanding `type` argument
is separated from arguments matching struct parspec fields. To minimize
disruption the new PARAM_SIMPLE() macro takes parameters in the order of
the previous PARAM() definition.

Refs #3250

We had everything we needed to make this happen, except for the mismatch
between parameter names pool_xxx and struct member names xxx_pool.

Refs #3250

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

We don't need a delay, we need to sync operations.

This puts client.identity at the same level as client.ip which happens
to be its fall-back before being explicitly set.

This change increases the initial size and reduces the low watermark.

RFC7540 says this:

> Flow-controlled frames from the sender and WINDOW_UPDATE frames from
> the receiver are completely asynchronous with respect to each other.
> This property allows a receiver to aggressively update the window
> size kept by the sender to prevent streams from stalling.

The default parameters are very much on the low-latency aggressive
updates end of the spectrum, which increases asynchronicity at the
expense of determinism in test cases.

The tweaks made by varnishtest allows basic tests to send a few request
bodies before being bothered by window update race conditions. Test
cases that cover h2 flow control or anything else related to window
updates may reset parameters or pick other specific values. This frees
us from a bunch of barriers where the purpose of mitigating this race
was rarely even documented.

This successfully passed the following test locally:

    git grep -Fl +http2 -- '*.vtc' |
    xargs bin/varnishtest/varnishtest -i -n100 -j32

We can hope that h2 test cases will be overall more stable from now on.

Refs #3442