See liburing commit 834496358870cb272f98cf22b3fe0307c83a526d

Fixes #26 specifically, we are still missing similar handling in other
places.

2d468a6f gave the clue:

When fellow_cache_obj_lru_touch() raced fellow_cache_lru_work(),
we would put the fco's fcs on the lru list twice: once from
_touch and then from _lru_work().

Fixes #25

See next commit for fix

This reverts commit bf1e9e71.

Motivated by #25, which looks like a self-induced deadlock
in fellow_cache_lru_work()

I suspected we could run into an infinite loop here. Suppose there is
only one fco on the LRU and we fail to mutate it, then it was
re-inserted again and again.

Related to #25, but I am not sure yet if it is the root cause

Avoid memory LRU racing disk LRU.

Disk LRU uses the varnish-cache LRU facility, which works by setting
the OC_F_DYING and gaining one reference, resulting in two references.

One is lost again by the thread initiating the LRU nuke, the other by
the EXP thread. Between the two events, the refcnt is one again, thus
stvfe_mutate could race.

I believe this fixes #23 and #24. If not, please reopen

Tests #22

the test case from the next commit exposed a deadlock because the
only object in the test would consume all memory und could not
get LRUd because fellow_cache_async_write_complete() would hold
the fco mtx during log submission.

UINT16_MAX would be just over a disk block, and allocating another
3.93k for a single additional segment does not make sense.

	(gdb) p /x sizeof(struct fellow_disk_seg) * 65534 +
		sizeof(struct fellow_disk_seglist)
	$7 = 0x37ffd0

Also fix a potential overflow, where a uint16_t was incremented after
clamping to UINT16_MAX.

Tests #22

Fixes another case of #22

Fixes one case for #22