it needs to be based on the space to be returned, not on the space to be still
allocated on disk.

before this change, it was taken as excluding struct fellow_cache_seglist,
and was correctly used at the call sites changed with this commit
(where (size - sizeof *fcsl) was used as the argument).

However, for the calls from
- fellow_busy_obj_alloc()
- fellow_cache_obj_get()

there was a mismatch with the caller's size value.

seen during internal testing:

 #13 0x00007efc94253e32 in __GI___assert_fail (assertion=0x7efc935ef349 "FCO_REFCNT(fco) <= 2",
    file=0x7efc935ee10f "fellow_cache.c", line=6106,
    function=0x7efc935ef2d4 "void fellow_cache_obj_delete(struct fellow_cache *, struct fellow_cache_obj *, const uint8_t *)") at ./assert/assert.c:101
 #14 0x00007efc935c7f66 in fellow_cache_obj_delete (fc=0x7efc93a41300, fco=fco@entry=0x7efc4778a000,
    hash=hash@entry=0x7efc2ea04270 "\016\351S~\a\346\353҄B\256x\346Mx\375P\211Hz\377U\337\030ol\207Y\276䯒")
    at fellow_cache.c:6106

reason: ongoing I/O on segments:

(gdb) p fco->fdo_fcs.refcnt
$19 = 3
(gdb) p fco->fcsl->lsegs
$20 = 3
(gdb) set $i = 0
(gdb) p fco->fcsl->segs[$i++]->state
$21 = FCS_INCORE
(gdb) p fco->fcsl->segs[$i++]->state
$22 = FCS_READING
(gdb) p fco->fcsl->segs[$i++]->state
$23 = FCS_READING

so:

- we can not make assumptions on the number of references
- we need to wait for any I/O, not just writing and seglist read

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

Adjust tests to changes in varnish-cache

Ref f1fb85fed1f943a2005d7da06de94ff6fa6cc0e2

Ref #65

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