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