Implements most of #17, except that we would like to restore OA_VARY
with the log read...

This should be backwards and forwards compatible, because the default
in both cases is 0, and varnish-cache will not use the bitfield
if it is 0.

Closes #16

Ref #16

In stvfe_dskoc_fco() we change the oc's stevedore to memstv only
_after_ we have taken a refernce via fellow_cache_obj_get() and thus
potentially put the fco onto the lru list.

This order is important, because other requests racing on
stvfe_dskoc_fco() need to also go through fellow_cache_obj_get() until
the memstv object has been established for real.

Yet this opens a window for a window where an fco is on LRU with
oc->stobj->stevedore still set to dskstv, even without dirty reads,
and even more so with dirty reads.

Because any additional synchronization here could kill performance, we
handle this outdated read in stvfe_mutate by not touching the object
(yet). It will be hit the next time we iterate the LRU list.

Fixes #13, hopefully.

Flexelint does not approve of

This reverts commit a1f5225e.

Because of #14 I would like to understand if #13 is really a genuine
bug or some odd consequence

This bug was also present in varnish-cache (will document) and found
its way into fellow through the api-definition-by-example paradigm of
varnish-cache:

In varnish-cache vbf_stp_error(), an existing storage object is freed
to be replaced with a new one, potentially from a different storage
(usually -sTransient).

In this case, ObjBocDone is not called, because the boc is to be
preserved - from the client's perspective, the backend transaction is
still in progress, and the client is waiting for the busy object to
finish.

At the storage level, however, the process of creation of a new object
_is_ finished, and any busy object state which the storage might keep
needs to be finalized.

So, if oc->boc is not NULL for an ObjFreeObj() call, the stevedore
needs to finish any busy object transaction.

Fixes #14

Ref b7ac17d9

make distcheck works now

Ref aa35f2b3

Should fix #9

and how they relate to cache usages.

Closes #5

They also get updated during resurrection when the checkpoint
logs are output.

Implements #6

closes #7

Closes #4

It seems to have caused confusion regarding the relation between io_uring
and the fellow memory cache, which exists only to the extent that io_uring
manages IO in and out of it.