For the build jobs we can directly use the target images and avoid the
nested docker invocation. For other jobs or Dockerfiles where centos:7
is used we can switch to a self-updating fedora:latest image.

Better diff with the --ignore-all-space option.

It reached EOL almost 2 years ago, but the architectures we cover in CI
had 2 extra years of long term support that is coming to an end this
month.

With CentOS reaching EOL at the end of the month and CentOS Stream 9
flaky packaging jobs, we don't need to keep them around. For el9 builds
we rely on the almalinux:9 image.

This is an attempt at speeding up this job that usually takes three time
as long as other distcheck jobs.

I don't understand why they didn't maintain the unversioned centos:stream
tag as a kind of latest tag after dropping the actual centos:latest tag.

The plain "stream" image has not been updated for a year, and instead of
being the equivalent of a "latest" tag it just appears to be frozen.

Since there isn't an automatic centos-stream upgrade path, let's target
version 9 explicitly for now.

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

Ubuntu noble tries to use `fchmodat2` (new syscall) and gets permission denied instead of ENOSYS.

This is a small security risk but it's running inside of circleci containers anyway so i think its acceptable.

There appears to be a race condition with distcheck where test-suite.log
is removed and then another attempt at removing it fails:

    [...]
    test -z "test-suite.log" || rm -f test-suite.log
    rm -f libtool config.lt
    find . '(' -name '*.gcda' -o -name '*.gcda' ')' -exec rm '{}' ';'
    rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
    rm -f cscope.out cscope.in.out cscope.po.out cscope.files
    find: ./test-suite.log: No such file or directory
    [...]

It is unclear which find command is choking on test-suite.log, there
doesn't seem to be a make rule running find and targeting this file.
Could it be the find command listed in the output collecting file names
like test-suite.log and then failing to test it against the -name
filters after it got removed? That would be infortunate for a find
implementation.

Since alpine is not a platform we officially support, and after failing
numerous times to reproduce the link outside of the CI environment, a
simple make check is good enough and it will remove a lot of noise.

In an attempt to avoid EAGAIN failures on pthread creations with ASAN
and UBSAN sanitizers enabled.

The current debian:latest image still ships a 32bit variant, whereas
ubuntu:focal, next in line after ubuntu:bionic, no longer does.

https://discuss.circleci.com/t/remote-docker-image-deprecations-and-eol-for-2024/50176

Rawhide is not stable and we already have a job for the latest stable
branch.

It is not obvious how we could trigger a gmtime_r() EOVERFLOW on 32bit

Thank you phk for pushing me back onto the right track at a late hour.

Ref #3308

I believe we get those when we have "subdir-objects", which we do now.

We can get rid of autogen.des' egrep command used to silence this
warning too. In fact we can even remove the subshell and simply
call autoreconf directly. The problem with egrep is the loss of
a meaningful exit status for the autoreconf invocation.

I also enabled autoreconf's verbose output.

Conflicts:
	autogen.des

The simple fact that Witness records might show up in the log might
break logexpect commands. There's no reason why we'd want to expect
Witness records since their purpose is to be checked after the test
finishes.

This change introduces a top-level make witness target that builds a dot
graph and if graphviz is available, an SVG file as well. A shell script
replaces the previous python script that no longer works. Instead of
fixing witness.py, which is probably trivial, the shell script does an
intermediate pass and programmatically looks for cycles using tsort(1).

Checking lock dependencies becomes actionable in a CI context.

The script also takes explicit test directories on purpose, to have the
ability to aggregate test results from multiple executions. For example
when the test suite is run on various operating systems or with varying
privileges to cover feature-conditional tests.

Conflicts:
	tools/witness.sh

The 6.0 branch does not contain the dT change in the vtc output, so
columns collected by the shell script were off by one.

Performing the conversion on the stack could lead to a buffer too small
to store the string representation of the IP address. There is no test
case because the error handling is output to stderr.

Refs #3765

Conflicts:
	bin/varnishd/cache/cache_vrt.c

Conflicts:
	bin/varnishd/http2/cache_http2_session.c

This to silence errors on OSX where apparently int64_t isn't type
equivalent to intmax_t, causing printf-errors when using %jd.

Fixes: #3699

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.

Conflicts:
	include/tbl/params.h

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.

Conflicts:
	include/tbl/params.h

Since http_req_size was already established for this purpose, and is
now enforced for h2 traffic, it should naturally become the basis for
the MAX_HEADER_LIST_SIZE setting in the initial SETTINGS frame sent
to clients.

The h2_max_header_list_size parameter will grow a new purpose.

Conflicts:
	bin/varnishtest/tests/t02000.vtc
	bin/varnishtest/tests/t02005.vtc
	include/tbl/params.h

With the exception of h2_max_header_list_size that is not advertised as
such despite being ent as part of the initial SETTINGS frame. The same
parameter also sees its default and maximum values updated to 2^32-1.

This is based on this sentence from rfc9113:

> The initial value of this setting is unlimited.

This aligns the h2_max_header_list_size parameter with the values set in
h2_settings.h for MAX_HEADER_LIST_SIZE.

Conflicts:
	include/tbl/params.h

For the sole purpose of having these limits tested in a single place.

Refs #3709
Refs #3892

Conflicts:
	bin/varnishd/http2/cache_http2_hpack.c