https://github.com/varnishcache/varnish-cache/pull/4013 fixes two
issues in Varnish-Cache, which are relevant for SLASH/fellow and of
which the first is the root cause of #33.

This commit works around these issues until the fix gets merged:

Because of the wrong use of the .objtrimstore API function by
varnish-cache, we remove it from our obj_methods and exploit the fact
that varnish-cache always sets the OA_LEN attribute when the object is
complete: We move the trimstore function there, effectively calling it
at the right time only.

The inefficient memory allocation fixed in the second commit of
VC#4013 is particularly relevant for fellow, because it causes the
allocation code to assume that the object might grow up to the maximum
possible size, which causes a substantial over-allocation. We work
around this issue for the case that a 304 copy is made from fellow to
fellow by using private thread-local storage to emulate basically the
same function as the #4013 fix.

Closes #33
Ref https://github.com/varnishcache/varnish-cache/pull/4013

Ref #33
Ref https://github.com/varnishcache/varnish-cache/pull/4013

These would have made analyzing #33 much easier. :|

motivated by #32

Spotted by Thomas Gleixner <tglx@linutronix.de>, THANK YOU

forkrun() never properly handled the case that a child exited before
the timeout expired, because we had failed to block the signal and
hence never received a SIGCHLD. This was overlooked because this
functionality was never relevant (it only delayed test execution) and
because we did not explicitly test it.

Related to #31

Should fix #32

See #31

It seems with the recent debian updates on my machine, some change
of timing/scheduling has come which makes flock() fail when the
lock holder is being killed by the timeout code in forkrun()

For future reference: logs/20231026_apt_history.txt

Making a full copy of the logbuffer just to access four members
was not justified. The original idea was to re-use logbuffer_fini,
but, effectively, only buddy_return1_ptr_page() was called.

In particular with uint8_t, we risk writes to be non atomic and
overwrite neighboring members

Ref #28

Ref #28

Ref #28

Weird - I do not understand why this did not pop up earlier?

Conflicts:
	src/Makefile.am

with 6abc7c970dd5be381e588b9d0234c385a5a6d0d7 in liburing,
io_uring_prep_fallocate() arguments were (rightly) changed
from off_t to __u64.

Reflect this change. Also note that our struct fellow_io_discard
already used uint64_t.

Reported by Flexelint

Before:

$ find . -name \*.so| xargs nm|grep simple_task_
000000000004ffd0 T fellow_simple_task_run

After:

$ find . -name \*.so| xargs nm|grep simple_task_
<EOF>

Motivated by #27

See liburing commit 834496358870cb272f98cf22b3fe0307c83a526d