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

The message makes very little sense when you read it, and it was only
a pure accident which finally resolved what it means:

    Info 768: global struct member 'backend' (line 51, file cache/cache_backend.h) not referenced
    cache/cache_backend.h  51  Info 830: Location cited in prior message

If you have:

	struct backend;

	void somefunc(struct backend *);

	struct backend {
		...
	};

All is fine.

But without the `somefunc` prototype, the first vacuous mention of
`struct backend` is unused, and FlexeLint uses the name *of* the
struct as the name of a field *in* the struct, and compounds the
confusion by emitting the message on the line where struct backend
is finally flushed out.