https://github.com/vtest/VTest/pull/32

This should be a no-op on all contemporary UNIX implementations, but
let's see what vtest tells us...

It's amazing how long time it takes to find a delay of half a second...

or rather, has been for some time now.

and document the default of the other methods.

Ref #4036

There is a default value when the property is not implemented and has no
callback.

Fixes #4036

of 08350519

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

The objiterate_f interface requires that OBJ_ITER_END be sent,
preferrably with the last chunk of data, but at least after it.

It was not documented explicitly anywhere, but the len/wsl argument to
STV_NewObject() is the amount of space to allocate for all
OBJ_VARATTRs combined which are going to be written to this
object. For now, these are OA_HEADERS and OA_VARY only (see
include/tbl/obj_attr.h).

So for one, there is no reason to force this argument be greater than
zero when we know that no OBJ_VARATTRs are going to be set.

Secondly, this might actually represent a minor shortcoming of the
stevedore API, because the amount of space which a stevedore
implementation actually needs might be larger than what the simple
stevedores use. So for now, the semantics of this argument are, more
specifically, "the equivalent of space for OBJ_VARATTRs as for simple
storage". In practice, this probably does not matter much...

But even before this clarification, the API was not used consistently:

For the call from vrb_pull(), the maximum request body size (to cache)
was used as the wsl argument, yet it has nothing to do with the object
body size, it specifies the amount of space to allocate for variable
sized object attributes (see above).

For the call from cnt_synth(), a somehow arbitrary value of 1KB was
used.

In both cases, the amount of space actually required is zero, because
the only attribute used on the objects created is OA_LEN, which is
fixed and thus always present.

There are two sizeof calls here with the same semantics, make them the
same.

Initialize the private pointer directly, instead of indirectly via
the request struct.

This is to prepare for reuse, but arguably the new home might actually
be the better place?

This reverts commit 2cae3597.

See #4033

for consistency with (struct busyobj).vfp_filter_list

Struct vdp_ctx has wrk and vsl members, use these instead of req.

for improved greppability, cosistently name struct vdp_ctx * variables
vdc.

Ref 5583667f
Ref #4013

we need a signal if the fix is in

The 503 synth and 500 minimal response status codes are too misleading
in this context, where the failure is attributed to the client. Among
existing 4XX status codes, this is the closest if we stretch the timeout
definition to "didn't complete rapidly enough before the client went
away".

When copying a stale object after a 304 revalidation, we iterated over
it and allocated new storage for each storage segment.

So, at best, we kept the fragmentation of the existing object, or made
it even worse. This is particularly relevant when the existing object
was created from a chunked response, in which case the original
segments might have been particularly small and, consequently, many in
number.

Because we wait for the stale object to complete, we know the total
length (OA_LEN) upfront, and can ask the storage serving the copy for
exactly the right length. This is much more efficient, as
fragmentation is lowered and the storage engine might make a much
better allocation decision when it knows the full length rather than
getting piecemeal requests.

We implement the improved allocation scheme through additional state
kept for the duration of the template object copy: struct
vbf_objiter_priv holds the pointer to the newly created busy object,
the total yet unallocated length (initialized to OA_LEN of the existing
object) and pointer/length to the unused portion of the currently open
segment, if any.

It is my understanding that the objtrimstore stevedore API function is
only to be called once when the object is complete, which I believe is
also in line with the comment on ObjExtend() that "The final flag must
be set on the last call".

If this understanding of the API is correct, we did not adhere to it in
the fetch code when we made a copy of an existing stale object after a
304 response: There, we iterated over the stale object and did not set
the final flag just once when the object was complete, but rather after
each storage segment was copied.

This commit fixes this, adds some pedentry to the simple storage and
extends b00062.vtc to test this behavior specifically. On top, g6.vtc
also triggered without the fix but the duplicate trim detection in place.

This issue has originally surfaced in the SLASH/fellow storage where the
trimstore function implicitly asserted to only be called once.

Ref 115742b0
Ref https://gitlab.com/uplex/varnish/slash/-/issues/33