This should cure the situation when on testnodes /tmp/wcfs already exists
created without sticky bit.

So that multiple users can create things inside.

tFile registers itself to tDB so that defer(tdb.close) that each test does,
automatically close all files before trying to unmount wcfs. However if an
error happens inside tFile constructor - before the place where
`tdb._files.add(t)` was previously located, tDB.close won't close tFile.f,
which will leave opened file on the wcfs -> wcfs unmount will fail with EBUSY,
and wcfs will be killed with huge backtrace.

If we register tFile early, the problem - even if it happens inside tFile
constor - will be handled gracefully: opened file closed and wcfs unmounted
clearnly - for example with the following short and easy to understand traceback

    (1.venv) kirr@deb9:~/src/wendelin.core$ python -m pytest -x wcfs/
    ============================================== test session starts ==============================================
    platform linux2 -- Python 2.7.13, pytest-4.6.11, py-1.9.0, pluggy-0.13.1
    rootdir: /home/kirr/src/wendelin.core
    collected 28 items

    wcfs/wcfs_test.py ..F

    =================================================== FAILURES ====================================================
    ________________________________________________ test_wcfs_basic ________________________________________________

        @func
        def test_wcfs_basic():
            t = tDB(); zf = t.zfile
            defer(t.close)

            # >>> lookup non-BigFile -> must be rejected
            with raises(OSError) as exc:
                t.wc._stat("head/bigfile/%s" % h(t.nonzfile._p_oid))
            assert exc.value.errno == EINVAL

            # >>> file initially empty
    >       f = t.open(zf)

    wcfs/wcfs_test.py:1080:
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    wcfs/wcfs_test.py:322: in open
        return tFile(t, zf, at=at)
    wcfs/wcfs_test.py:477: in __init__
        mm.lock(t.fmmap, mm.MLOCK_ONFAULT)
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    >   PyErr_SetFromErrno(OSError)
    E   OSError: [Errno 1] Operation not permitted

    wcfs/internal/mm.pyx:112: OSError
    --------------------------------------------- Captured stdout call ----------------------------------------------

    M: commit -> @at0 (03db288d33c34955)
    >>> Change history by file:

    --------------------------------------------- Captured stderr call ----------------------------------------------
    wcfs: 2020/10/08 19:13:12 zodb: FIXME: open file:///tmp/testdb_fs.1HuVZF/1.fs: raw cache is not ready for invalidations -> NoCache forced
    E1008 19:13:12.030532    3251 wcfs.go:2450] kernel FUSE (API 7.26) does not support explicit data cache invalidation
    E1008 19:13:12.030780    3251 wcfs.go:2450] -> performance will be AWFUL.
    E1008 19:13:12.030796    3251 wcfs.go:2450] -> you need kernel which includes git.kernel.org/linus/ad2ba64dd489.
    E1008 19:13:12.030809    3251 wcfs.go:2450] -> (Linux 5.2+, or nxd-fuse-dkms package installed from navytux.spb.ru/pkg)
    W: wcfs: kernel FUSE (API 7.26) does not support explicit data cache invalidation
    W: wcfs: -> performance will be AWFUL.
    W: wcfs: -> you need kernel which includes git.kernel.org/linus/ad2ba64dd489.
    W: wcfs: -> (Linux 5.2+, or nxd-fuse-dkms package installed from navytux.spb.ru/pkg)
    ----------------------------------------------- Captured log call -----------------------------------------------
    WARNING  ZODB.FileStorage:FileStorage.py:398 Ignoring index for /tmp/testdb_fs.1HuVZF/1.fs
    ====================================== 1 failed, 2 passed in 2.10 seconds =======================================

Some wcfs bugs are aonly likely to trigger with GOMAXPROCS=1 (see
corresponding tox.ini history), same for 2. Go-fuse also has issues with
GOMAXPROCS=1 (https://github.com/hanwen/go-fuse/issues/261) that
sometimes manifest themselves as hangs with GOMAXPROCS=`nproc` too.

- it is more clear to run wcfs tests separate
- it was confusing to run wcfs unit tests as part of e.g.
  test.py/fs1-!wcfs (note the "!wcfs" = "non-wcfs")

go.mod is inside wcfs/ and if `go test ./...` is ran outside of it, it
autodetects to use GOPATH mode and fails to find imports used by wcfs.

To run wendelin.core tests under Nexedi testing infrastructure.

* kirr/t:
  X wcfs: make it to use go modules for dependencies

Still want to preserve GOPATH compatibility as working on several
repositories simultaneously is, unfortunately, currently not good via
modules

https://github.com/golang/go/issues/27542
https://github.com/golang/go/issues/37755

For GOPATH way of work (local development) wendelin.core has to be
symlinked from inside $GOPATH/lab.nexedi.com/nexedi/ and worked through
_that_ directory - else imports inside wcfs will fail.

* master:
  3rdparty/ccan: Update for build fix wrt recent gcc/binutils

We need the following patch of mine:

   http://git.ozlabs.org/?p=ccan;a=commitdiff;h=b97c7f0841f5173a07a2571f2c99f944d8405a90

Else in case of two files used simultaneously the index is messed up.
Fixes test_wcfs_watch_2files and now all wcfs tests pass again.

Reason: see comments.
Prerequisite to fix test_wcfs_watch_2files