This way when wcfs is started via _start it also takes default options
into account. Noticid while running test_join with
$WENDELIN_CORE_WCFS_OPTIONS set and not propagated to spawned wcfs.

go123 update is NFC.

Since ZBigFile keeps references to fileh objects that are created
through it it forms a file <=> fileh cycle that is not collected without
cyclic GC:

https://lab.nexedi.com/nexedi/wendelin.core/blob/v0.13-52-ga702d41/bigfile/file_zodb.py#L497
https://lab.nexedi.com/nexedi/wendelin.core/blob/v0.13-52-ga702d41/bigfile/file_zodb.py#L566-571

We did not noticed this leak until now because it is small, but with
upcoming wendelin.core 2 it is important to release a fileh, because
there is WCFS connection associated with fileh, and if fileh is not
released, that connection also stays alive, keeping on-WCFS resources
still being used, and preventing WCFS from being unmounted cleanly.

-> Add cyclic GC support to PyBigFile / PyBigFileH

NOTE: we still don't allow PyVMA <=> PyBigFileH cycles to be collected,
because fileh_close called from fileh.__del__ asserts that there are no
live mappings left. See added comments for details. There is no
known practical need to use such cycles, so this should be ok.

See also other patches on cyclic GC topic:

- 450ad804 (bigarray: ArrayRef support for BigArray)  // adds cyclic GC support for PyVMA
- d97641d2 (bigfile/py: Properly untrack PyVMA from GC before dealloc)

X bigfile/_file_zodb: Fix ZSync to close not only wconn, but also wconn.wc through which wconn was created

pywconnOf, before creating wconn, performs wc=wcfs.join(zurl) which
creates new filesystem-level connection to WCFS server. This wc is used
only to create wconn. So if we do not close wc, after releaseing wconn,
it will leak opened file descriptor, to e.g. .wcfs/zurl and prevent
tests from finishing cleanly.

Its just a debugging print - helpful to debug zwatcher, but not helpful
to understand which events the system was observing.

Helps to understand why if wcfs cannot be unmounted.

Don't use regular mutex to protect _zsyncReg updates as this can
deadlock because one of _zsyncReg mutators (on_zconn_dealloc) is invoked
by automatic GC that can be triggered any time.

The logic inside ZSync was correct, but it was incorrect to attach zsync
to zconn to stay alive and react when that zconn is garbage collected:
zsync._on_zconn_dealloc was not called because zsync itself was garbage
collected too.

This fixes many failures where wconn and associated pinner was not
released even though ZODB DB was correctly closed.

This makes sure to cleanup /proc/mounts from stale / broken FUSE
connection, and removes uninformational `assert not is_mountpoint` from
raising, thus, adding more noise in already very verbose wcfs-kill-dump.

Excercise the logic that keeps wconn <-> zconn in sync.

To known to which DB state WCFS connection corresponds. This is similar
to zodb.Connection.At() in ZODB/go and to zconn_at in ZODB/py.

wconn.at() will be used in the next patch to verify ZSync.

Manaully, because there is no automatic dependency tracking in
setuptools...

Dependency tracking is needed to avoid miscompilation after incremental
update under SlapOS/buildout/testnode/... when e.g. only .h was changed.

Tests inside wcfs/ care to do this, but e.g. test.py/fs-wcfs autospawns
wcfs servers during regular bigfile tests. If we don't stop spawned
wcfs, those processes will leak, and also they keep `nxdtest
test.py/*-wcfs` in "hung" state, because nxdtest is waiting for wcfs to
stop as wcfs stdout is connected to nxdtest input.

Currently kills wcfs in abrupt way, because graceful pinner shutdown is
not yet implemented there.

tWCFS is responsible for starting/mounting/unmounting/stopping wcfs
tDB uses tWCFS and provides commit/test service on top.

We'll use tWCFS in the next patch to unmount/stop WCFS processes that
are automatically spawned during test.py