For the old API, a variable assignment got lost.

Ref 12db7fc5

With the previous code, the compiler could have produced machine code
which produced a transient zero lsb when in fact it should have been 1.

Ref ba32426c
Ref #66

Fixes #44 properly

Ref https://github.com/varnishcache/varnish-cache/pull/4109

Ref #65

The .happy VCL variable now returns true only when the respective fellow
storage is open (has completed loading).

The b_happy VSL bitfield contains the happy state in individual bits,
updated at logbuffer_flush_interval. The least significant bit contains
the most recent happy state.

The semantics of the happy value are likely to change in the future.

Motivated by #66

No matter when we read the boc state, before or after ObjWaitExtend(),
we might read an inconsistent, outdated or too fresh, value with respect
to the available bytes returned by ObjWaitExtend(), because our read
does not happen from the critical region of ObjWaitExtend().

We work around this issue with two changes:

- in fellow_stream_wait(), call ObjWaitExtend again if the state as
  seen from outside ObjWaitExtend() changes.

- in fellow_stream_f(), use ObjWaitState() to ensure that the busy
  object is done when we are called with OBJ_ITER_END, which means
  that we are called on the last fcs.

Should fix #44 - please open if not

Motivated by #44

For an fco which failed mutation, any fcs of the same fco following
it would be skipped because of

		if (fcs->fco == fco)
			continue;

this was particularly relevant for b62.vtc, which creates just one
cache object.

With the fix, varnishtest -n10000 -j20 ... vtc/fellow_b00062.vtc
completed without any failure.

interestingly, this was missing since the initial public release

this could have lead to over-zealous LRU

avoid comparison between signed and unsigned.

We know that (have) is positive here because of the explicit test for
< 0 two lines above, so it is save to cast to the type of the rhd
operand.

Ref a9700c63
Ref #65

to match the result of io_uring

Ref a9700c63
Ref #65

explicit cast for errno assignment

Ref a9700c63
Ref #65

Found by flexelint

Ref a9700c63
Ref #65

Ref #65

Adjust tests to changes in varnish-cache

Ref f1fb85fed1f943a2005d7da06de94ff6fa6cc0e2

Add O_LARGEFILE just in case

Fix mode to 0600

Fixes the second part of #60

Ref: https://github.com/varnishcache/varnish-cache/pull/4056

Ref #60

If the page from the segmem pool is too big, do not just trim it, but
rather trade it for a smaller page if that is sufficient.

Ref #60

... if it looks like we were handling chunked encoding.

fellow has (and needs to have) its own strategy for allocating growing
objects and is basically working around the fetch_chunksize coming
from varnish-cache by recording if subsequent allocation requests are
growing the object (for chunked encoding) or are converging onto a
maximum (for content-length).

Now this strategy had an undesired side effect, that the newly
introduced fbo_segmem pool is always allocating the chunk size, but
the disk segment allocation was using the size from varnish-cache,
which, for the example in the ticket, would lead to 1MB chunks being
allocated, but trimmed down to only 16kb - for each allocation.

We now explicitly test if varnish-cache is requesting fetch_chunksize
and, if so, allocate the chunk size.

This brings the disk segment allocation in line with the mempool.

On the other hand, for chunked encoding, we will still over-allocate
and trim when the actual object is smaller than the chunk size, but
this is by design.

Fixes #60

while working on #60