Hopefully this should fix vtest errors on bsd/arm

Thank you to phk for the quick help!

I do not understand how to avoid the child panicking while it is being
killed for timeout. And removing the AZ() for this case only is not
a good idea.

***  v1    debug|Error: Child (36277) not dying (waitpid = 0), killing
***  v1    debug|Child (36277) died signal=6
***  v1    debug|Error: Child (36277) Panic at: Mon, 03 Jul 2023 15:18:50 GMT
***  v1    debug|Assert error in CLI_Run(), cache/cache_cli.c line 102:
***  v1    debug|  Condition((VCLI_WriteResult(heritage.cli_out, CLIS_OK, \"Ready\")) == 0) not true.

An r3940 vtest failure on freebsd seems to suggest that the child
does not terminate while blocking in a write.

***  v1    debug|Error: Child (74042) Panic at: Mon, 03 Jul 2023 13:40:40 GMT
***  v1    debug|Assert error in CLI_Run(), cache/cache_cli.c line 102:
***  v1    debug|  Condition((VCLI_WriteResult(heritage.cli_out, CLIS_OK, \"Ready\")) == 0) not true.

This might need another iteration.

as seen in varnishtest:

***  v1    debug|Error: Child (0) not dying, killingChild (74042) died signal=6

This makes obvious what is used for statistics purposes and what is used
to maintain the pool queue. In particular, the pool::nqueued field has
nothing to do with pool::ndequeued.

printf debugging showed that the initial VSMW_New() call did not go
through vsm_vsmw_lock() / vsm_vsmw_unlock() simply because the
function pointers were not initialized yet.

This patch moves the init just after their initialization.

child_main() was previously called right after VSMW_New(), and
VSM_Init() is almost the first thing which child_main() calls, so
this move is mostly cosmetic.

Seen staring at #3948

When a child did not come up within cli_timeout, varnishd startup
would hang indefinitely.

We add startup_timeout specifically for child startup.

To facilitate the transition, we use the maximum of cli_timeout and
start_timeout (suggested by Dridi, thank you) and add a tip if
startup_timeout is not used.

We avoid the previous harsh exit(1), primarily to make the vtc_varnish
facility work.

The test case uses both vtc_varnish and vtc_process to exercise the
different code paths for implicit startup vs. cli "start".

Fixes #3940

For both processes, dump the screen before checking expectations. For
p1, we make sure we have something to show before proceeding, and can
abuse CLI serialization for that. Since p2 was already waited for, the
screen dump was already guaranteed to succeed, on the other hand the
superfluous p2 -wait can go away.

Motivated by #3948

The VCC_GlobalSymbol() function might be called twice for the same
symbol. For example a subroutine symbol may be created when the sub
keyword is first encountered, but it was referenced by a call action
before the subroutine definition.

The main problem the leak is causing is lsan's output polluting test
cases looking at the screen output of varnishd, making the lines we
care about scroll out to oblivion. To remedy this, VCC_GlobalSymbol()
idempotence becomes free of side effects.

As noted in 31baed29, my commit
0c1aef58 was wrong, and it was even
worse than we thought:

Despite what the linux man page suggests, the close_range()
declaration is in unistd.h on Linux like on freebsd.

We do not actually need linux/close_range.h, because it has only
macro definitions which we do not need.

We now add a specific configure test if close_range() not only exists
but also works.

Closes #3905

But retain the ability to specify them:

    make VGZ_CFLAGS=-Wfoo

We may need them again if new warnings crop up when we sync with zlib in
the future, or if we retire libvgz in favor of a vanilla zlib.

Refs 3df9cdc1

We have two forms of -efile(766, config.h) globally

I believe this is the most invasive method:

-e{766} has no effect
--e{766} applies to the whole file
-efile(766, ...) in flint.lnt applies to the (sub)tree

This was fixed after several attempts in the past [1] and I convinced
myself that I was doing it wrong when I implemented generic VSC rules
similarly to how VTC rules were centralized [2] but some lessons will
never be learned.

The reason why I was so easily convinced is that the '-local' suffix
is clearly documented, but the '-am' one is not, which leads me to
believe that it is an implementation detail we shouldn't rely on. The
documentation clearly states the lack of '-local' ordering, one more
reason not to rely on 'check-local'.

If we can use neither 'check-local' nor 'check-am' reliably for the
test suite refresh vs execution ordering, maybe there's a simpler
solution?

Fixes #3942

[1] 85e3d442
[2] dcaf616c

Fixes #3943

https://gitlab.com/uplex/varnish/slash/-/issues/13 is an example where
9 stack frames are used by abort handling alone.

pthread_* calls don't set errno but return it instead. This cocci patch
ensures we always use PTOK macro that sets errno in case of pthread calls
failures.

this happened on one of the uplex linux vtesters which runs
gcc and clang in parallel un-namespaced

*    top   VTEST Abstract UDS backend: change path, drop poll
**   top   === feature abstract_uds
**** dT    0.004
**   top   === server s1 -listen "@vtc.s1.sock" {
**   s1    Starting server
---- s1    Server listen address (@vtc.s1.sock) cannot be resolved: bind(2)

to have available a unique string for concurrently running tests
which is not a path.

from the log:

**   top   === shell -exit 1 -expect {failing as requested} {
**** top   shell_cmd|exec 2>&1 ;
**** top   shell_cmd|\tvarnishadm -n /root/VT/_vtest_tmp/vtc.37277.0dc3c11b/v1 vcl.load f1 /root/VT/_vtest_tmp/vtc.37277.0dc3c11b/f1
**** dT    27.789
**** v1    vsl|          0 CLI             - Rd vcl.load f1 vcl_f1.1686893821.277415/vgc.so 1auto
**** v1    vsl|          0 CLI             - Wr 300 62 VCL "f1" Failed initialization
Message:
	failing as requested

**** dT    27.893
**** v1    vsl|          0 CLI             - Rd ping
**** v1    vsl|          0 CLI             - Wr 200 19 PONG 1686893826 1.0
**** dT    32.987
**** top   shell_out|CLI communication error (hdr)
**** top   shell_status = 0x0002
---- top   shell_exit not as expected: got 0x0002 wanted 0x0001
*    top   RESETTING after ../../../../bin/varnishtest/tests/m00000.vtc
**** dT    32.988

in the most diff-friendly way.

If Mark Adler ever decides that the 21st century is real thing, we
will adopt his diff.

This should allow us to revert 79c7d175

Varnish historians claim to have evidence that the odd wording "from
mgt_param" could have been an unintended side effect of a struct
rename in ancient times at around 2011. (82411494)

To keep things simple, the open delay is global - the delay of
the last debug stevedore applies to all of them.

With the recent change to stream the request body to the backend like
chunked encoding does, even when we know the content length, two test
cases became sensitive to the timing of window updates. The data frames
contain for the most part a 16kB payload, which happens to be the same
as fetch_chunksize's default value.

With a value of 64kB, corresponding to one more byte than the default h2
initial window, we are garanteed to never risk a race between the VFP
consuming the h2_rxbuf and the h2_sess task monitoring it to send window
updates.

This is also a good occasion to exercise stream.peer_window in t02019.

Refs #3878
Refs #3934