Unlike session timeouts, they were not falling back to their parameter
counterparts from NAN. Since NAN is not allowed in VCL, they now behave
like session timeouts, returning their value or falling back to the
parameter when unset.

We can't use NAN in VGC code today, so in order to convey the lack of
timeout setting in a backend definition, only a negative value makes
sense since zero will eventually mean zero instead of undefined.

This is an implicit breakage of the VRT ABI for the meaning of struct
vrt_backend.

They were already relying on NAN to fall back to parameters.

The timeout type is the authority from which both the tweak and flag
are derived.

For all intents and purposes, it currently is exactly the same as the
timeout tweak. The duration parameters are either not really timeouts,
or timeouts that cannot be disabled. In other words, the timeout tweak
will grow the ability to formally disable a timeout.

Refs #3045

From now on, INFINITY disables the timeout and NAN is no longer allowed.

Refs #3045

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.

That is to say, when we can actually do that.

This is a partial revert of 582ded6a to
restore the assumed onerror=continue behavior for ESI includes, unless
the feature flag esi_include_onerror is raised.

The part of the change that considers all status codes besides 200 and
204 to be errors for ESI includes remains. A test case covers VCL's
ability to "bless" error responses by overriding resp.status, allowing
ESI delivery to continue on this criterion.

Fixes #4053

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

When we introduced checking ESI includes for status 200 or 204, we
would only (potentially, depending on the onerror attribute and
esi_onerror_continue parameter) abort ESI processing for includes
with a non-zero length.

This patch makes behavior consistent to not depend on whether or not an
include is empty.

Fixes #4070

Ref 2d494dc7
    bb3d027b

We no longer need to mark used vmods in subroutines (see previous
commit)

to avoid using stale pointers after a rollback.

Before this change, we would call VRT_priv_* only once per subroutine,
which can be *) a nice performance optimization, but leaves us with stale
pointers after a rollback.

Rather than adding complications for the rollback case just to keep the
option of the "per subroutine pointer cache", just retrieve a fresh
priv pointer every time.

The other use of the per subroutine initialization was error handling,
which needs additional code outside the function arguments, simply
because a return statement is not possible within function arguments. We
removed the requirement for error handling in the previous commit by
making sure that VRT_priv_{task,top} always return a valid pointer.

Fixes https://github.com/varnish/varnish-modules/issues/222

Alternative implementation to #4060

*) It is not an optimization in all cases, for example the priv pointers
   were intialized unconditionally, even if code using them was not
   reached - but then again, this is something C compilers might
   optimize...

this is in preparation of a follow up commit

This reverts the code change from commit 6d423aa5,
keeps the test case and adds a VDP_Close() for the case that the
transport deliver function is not called.

Part 2 of the fix for #4067

Conflicts:
	bin/varnishd/cache/cache_req_fsm.c

Part 1 of the fix for #4067

this is for consistency, to simplify parsing and to reduce the amount of
data logged with VSL.

Motivated by #4042

Signed-off-by: Asad Sajjad Ahmed <asadsa@varnish-software.com>

Refs #4063

Very much looks like copy-pasta in ede8c3db

JAIL_FIXFD_VSMMGT and JAIL_FIXFD_VSMWRK work on directories but,
as the name implies, JAIL_FIXFD_FILE not.

This adds coverage for a non-delivery transition from vcl_hit, where the
busy objcore would drop its sole reference in the event of a grace hit.
The lack of coverage was visible in the gcov dashboard:

    669   580   if (busy != NULL) {
    670   0     	(void)HSH_DerefObjCore(wrk, &busy, 0);
    671   0     	VRY_Clear(req);
    672   0     }

There should now be at least one pass inside this block.

Refs #4032

Refs #4055

When a VMOD adds a CFLAG with `libvmod_$1_la_CFLAGS` the object name is no
longer `vmod_$name.lo` but `$library-vmod_name.lo` this changes the
build order such that the VCC autogenerated files would not be
guaranteed to compile first causing compilation issues.

For chunked encoding, we do not know how big the object is ultimately
going to be, so VFP_GetStorage() called ObjGetSpace() with the
fetch_chunksize parameter in this case.

Yet which size is best might differ for different storage engines, and
having the information that the caller does not know the final size
might be relevant. Storage engines could guess that if a request came
in for fetch_chunksize that this _might_ be the "chunked" case, but
that heuristic would be wrong for Objects of just that size advertised
via Content-Length.

So this patch takes the guesswork out of the game by just passing the
magic 0 value down to the storage engine to mean "give me some good
chunk of bytes, I do not know how much I am going to need".

Since, we seems to not use it at all.
Signed-off-by: Asad Sajjad Ahmed <asadsa@varnish-software.com>