Maybe it should gain a boc_state_e * argument to return a consistent
state value?

It turns out we still need it in a couple places.

When TMPDIR is much longer than /tmp, it becomes easy to run out of
abuf. Since abuf and pbuf are initially used to hold an IP address
and a port number, it becomes explicit in their declaration. Likewise
the new lbuf may hold a file name and safely be reused for CLI auth
and other purposes.

The test is racy, we should always perform the backend fetch to reach
the "barrier b1 sync" in the server body, otherwise the test will be
stuck on the second barrier sync until timeout.

Fixes: #4098

The opposite of 'EXP_Ttl(req, oc) > req->t_req' should not have been
'EXP_Ttl(NULL, oc) < req->t_req'. If we somehow enter the lookup when
the two operands are equal, the objcore suffers a phenomenon known as
Schrödinger's expiry.

The chances of running into this scenario range from epsilon to 100%.

Because 't_req' is stable across restarts, a soft purge will reliably
trigger this case.

Test case by Alve Elde who first demonstrated the problem.

As both the varnish working directory and the secret file may
pre-exist, this ensures permissions remain restrictive on it.

There's no way to probe the current push status or maximum frame size.

Except that the old default value replaces the maximum one. Aligning
with the literal maximum value for the underlying HTTP/2 setting breaks
32bit builds because the byte tweaks take a detour via ssize_t. When it
casts to uintmax_t the MSB is propagated all the way, triggering the
following error at build time:

> 4294967295b is too large for this architecture.

Instead of fighting a tweak that is clearly wrong, grant h2 clients a
maximum of 2GB of uncompressed headers (instead of 4GB) that will never
happen, because h2 is overall much wronger.

This parameter has a new role that consists in interrupting connections
when decoding an HPACK block leads to a header list so large that the
client must be stopped.

By default, too large is 150% of http_req_size.