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.

0051cbe3 did not work on
solaris-descendents, the man page clearly states that the size argument
also determines the buffer to be malloc()ed for a NULL buffer argument.

55995ab0 turned the VSIG_* flags into
counters, and changed the top of the VUT_Main() accordingly.

We need to reflect the change also further down in the tight loop
calling VSLQ_Dispatch().

Fixes #3436

This is enforced by libvcc for static backends, but not guaranteed for
dynamic backends. With no fallback we cannot meet the requirement since
HTTP/1.1 that requests always have a host header if it is unset from VCL,
and probes expect hosthdr to always be set.

Dridi pointed out that there was still a colon missing to conform with
the SLT_Notice documentation in include/tbl/vsl_tags.h

Spotted by Coverity.

seen in vtest:

**** v1   vsl|       1004 Begin           b bereq 1003 fetch
**** v1   vsl|       1004 VCL_use         b vcl1
**** v1   vsl|       1004 Timestamp       b Start: 1602334643.946723 0.000000 0.000000
**** v1   vsl|       1004 BereqMethod     b PUT
**** v1   vsl|       1004 BereqURL        b /2
**** v1   vsl|       1004 BereqProtocol   b HTTP/1.1
**** v1   vsl|       1004 BereqHeader     b Host: 127.0.0.1
**** v1   vsl|       1004 BereqHeader     b Content-Length: 250000
**** v1   vsl|       1004 BereqHeader     b X-Forwarded-For: 127.0.0.1
**** v1   vsl|       1004 BereqMethod     b GET
**** v1   vsl|       1004 BereqHeader     b Accept-Encoding: gzip
**** v1   vsl|       1004 BereqHeader     b X-Varnish: 1004
**** v1   vsl|       1004 VCL_call        b BACKEND_FETCH
**** v1   vsl|       1004 VCL_return      b fetch
**** v1   vsl|       1004 BackendOpen     b 26 s1 127.0.0.1 36579 127.0.0.1 60878 connect
**** v1   vsl|       1004 Timestamp       b Bereq: 1602334643.956883 0.010159 0.010159
**** v1   vsl|       1004 FetchError      b HTC eof (-1)

Ref #3433

noticed by Dridi here:
https://github.com/varnishcache/varnish-cache/pull/3434/commits/f9f40b991f301fb96d2e2d0d52b86c3d4b1f9f7f#r502302785

The reference count returned already is an unsigned value

Test case by Reza, thank you

Fixes #3433
Closes #3434

SLT_Notice requires messages to be prefixed by the vmod name. Using this
format for notices only would appear inconsistent, so we change all
shard log messages to that format.

Making use of the PRIV_TASK `.free()` callback, we can finalize the
reconfiguration when the tasks ends, in case `.reconfigure()` has not
been called explicitly. o/ Dridi

Also turn `SLT_Error` `"(notice)"` logs into `SLT_Notice`.

This cursor is the simplest of all as of now, and also the fastest way
to skim through a -r input when it's a regular file. This is essentially
a file cursor with much less memory churn.

On a 13GB log dump captured during a performance benchmark varnishlog
takes around 6m15s to print all the transactions to /dev/null but the
mmap cursor consistently reduces this time to around 1m01s.

This is particularly useful to audit logs at rest, be it error logs
after an incident or transactions captured during a benchmark-type
scenario.

The shard director had the limitation to only support adding/removing
backends of one instance before `.reconfigure()` on that instance had
to be called, then the next instance could be changed.

This limitation came from the time when it was still unclear that
calling `VRT_priv_task()` on a per-object pointer was the accepted
interface for per-instance privs (varnish historians' recommended read:
https://github.com/varnishcache/varnish-cache/wiki/VIP1:-PRIV_*-visibility-and-lifetime-control
)

It is about time to lift that limitation now. o/ Dridi

Ref #3407