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 c1c9c4c7

forgot some members in the calculation, so on SmartOS we hit
an assertion that the resulting pool is below 4KB

cast to pointer from integer of different size seen on smartos

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