It seems some OSes fail the call despite having it in the header file.

Fixes #68

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