* master:
  tests: Reset transaction synchronizers before every test run

Else, e.g. after a failing test, that closed its storage and DB, but not
all Connections, another test, just by starting new transaction, would
invoke synchronization on that unclosed connection, which will try to
access closed storage and likely fail.

Fixes e.g. https://nexedijs.erp5.net/#/test_result_module/20210401-31B27B3D/5

Crash scenariou is the same as described in 5a5ed2c7 (tests: Force-close
ZODB connections in teardown, that testing code forgot to explicitly
close). Only now we try to isolate tests from each other not only for
different modules, but also for tests inside the same module.

* master:
  lib/zodb: Add tests for critical ZODB properties that Wendelin.core 2 will depend on
  *: tests: don't hang on exception in non-main thread

The tests verify that there is no concurrency bugs around load,
Connection.open and invalidations. See e.g.

https://github.com/zopefoundation/ZODB/issues/290
https://github.com/zopefoundation/ZEO/issues/155

By including the tests into wendelin.core, we will have CI coverage for
all supported storages (FileStorage, ZEO, NEO), and for all supported
ZODB (currently ZODB4, ZODB4-wc2 and ZODB5).

ZEO5 is know to currently fail zloadrace.
However, even though ZODB#290 was fixed, ZEO5 turned out to also fail on zopenrace:

        def test_zodb_zopenrace():
            # exercises ZODB.Connection + particular storage implementation
    >       zopenrace.main()

    lib/tests/test_zodb.py:382:
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    <decorator-gen-1>:2: in main
        ???
    ../../tools/go/pygolang/golang/__init__.py:103: in _
        return f(*argv, **kw)
    lib/tests/testprog/zopenrace.py:115: in main
        test(zstor)
    <decorator-gen-2>:2: in test
        ???
    ../../tools/go/pygolang/golang/__init__.py:103: in _
        return f(*argv, **kw)
    lib/tests/testprog/zopenrace.py:201: in test
        wg.wait()
    golang/_sync.pyx:246: in golang._sync.PyWorkGroup.wait
        ???
    golang/_sync.pyx:226: in golang._sync.PyWorkGroup.go.pyrunf
        ???
    lib/tests/testprog/zopenrace.py:165: in T1
        t1()
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

        def t1():
            transaction.begin()
            zconn = db.open()

            root = zconn.root()
            obj1 = root['obj1']
            obj2 = root['obj2']

            # obj1 - reload it from zstor
            # obj2 - get it from zconn cache
            obj1._p_invalidate()

            # both objects must have the same values
            i1 = obj1.i
            i2 = obj2.i
            if i1 != i2:
    >           raise AssertionError("T1: obj1.i (%d)  !=  obj2.i (%d)" % (i1, i2))
    E           AssertionError: T1: obj1.i (3)  !=  obj2.i (2)

    lib/tests/testprog/zopenrace.py:156: AssertionError

Previously if an assert or something failed in spawned thread, the main
thread was usually spinning indefinitely = tests hang. -> Switch all
threading places to use sync.WorkGroup and this way if a thread fails,
all other threads are canceled and the exception is reported back to
wg.wait in main thread.

Since we start to go this route, NotifyChannel is reworked to fully use
channels instead of busy-waiting.

* master:
  .gitignore += *_dsoinfo.py

setuptools_dso 2 started to emit those autogenerated files.
See https://github.com/mdavidsaver/setuptools_dso/pull/15 for details.

* master:
  tox: v↑ NEO  (1.9 -> 1.12)
  Require Zodbtools
  Drop support for ZODB3

NEO 1.9 was released in 2018 and is outdated by now. NEO 1.12 is
currently the latest NEO release.

After switching to ZODB >= 4 in the previous commit, we can safely
require zodbtools, because there is now no conflict in between
ZODB3/ZODB eggs.

It's been a while since last ZODB3 3.10.7 release in 2016 and the last
commit in upstream ZODB3 repository (3.10 branch) is from 2017. The
world switched since then to ZODB4 and to ZODB5 after that.

We were still requiring ZODB3, because ZODB3 3.11 egg was just a
dependency on newer ZODB, ZEO, BTrees and persistent; and this way we
could be supporting all ZODB3.10.x and  ZODB4 and ZODB5 via ZODB3.11.

However upcoming Wendelin.core 2, for its proper working, needs MVCC
semantic as implemented in ZODB5. This forces us, even for ZODB4, to
backport non-trivial bits from ZODB5 (see [1]). Maintaining ZODB3
support at this point becomes non-practical, because, to our knowledge,
there is no wendelin.core user that plans to continue using ZODB3
without switching to at least ZODB4 in the near future.

So goodbye ZODB3. Even though ZODB still stays with us, it gives a
feeling similar to [2], because in 2014, when I was myself learning
ZODB, it was through ZODB3 - still at the time when all ZODB bits were
living together in one place.

[1] nexedi/ZODB!1
[2] https://lists.osuosl.org/pipermail/darcs-users/2008-September/014095.html

This will be used to implement both wcfs service and wcfs promise.

* master:
  tests: Don't try to access db.storage when automatically closing connections
  bigfile/py: Garbage-collect BigFile <=> BigFileH cycles
  bigfile/py: Move PyVMA's support for cyclic GC close to pyvma_dealloc
  t/tfault-run: Require bash
  t/tfault-run: Clear state from previous run before starting
  Add way to run tests via nxdtest

- it is more logical
- this way !wcfs tests don't try to excerceise wcfs functionality (and
  unexpectedly spawn wcfs server).

DB.close() does `del self.storage`.

https://github.com/zopefoundation/ZODB/blob/5.6.0-14-g0eae10cd0/src/ZODB/DB.py#L646

This way if DB was closed, but some conn(s) were not, it will crash in
teardown as e.g. below:

    _____________ ERROR at teardown of test_bigfile_zblk1_zdata_reuse ______________

        def teardown_module():
    >       testdb.teardown()

    bigfile/tests/test_filezodb.py:58:
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    self = <wendelin.lib.testing.TestDB_ZEO object at 0x7fb9c0216350>

        def teardown(self):
            # close connections that test code forgot to close
            for connref, tb in self.connv:
                conn = connref()
                if conn is None:
                    continue
                if not conn.opened:
                    continue    # still alive, but closed
                print("W: testdb: teardown: %s left not closed by test code"
                      "; opened by:\n%s" % (conn, tb), file=sys.stderr)

                db = conn.db()
    >           stor = db.storage
    E           AttributeError: 'DB' object has no attribute 'storage'

    lib/testing.py:217: AttributeError

The fix is simple - don't use db.storage at all, because it is not actually used in that code.

- use +D to request recursive search of everything under mntpt
- use -w to avoid seeing many-many warnings in case there are stale FUSE mounts.

DB.close() does `del self.storage`.

https://github.com/zopefoundation/ZODB/blob/5.6.0-14-g0eae10cd0/src/ZODB/DB.py#L646

This way if DB was closed, but some conn(s) were not, it will crash in
teardown as e.g. below:

    _____________ ERROR at teardown of test_bigfile_zblk1_zdata_reuse ______________

        def teardown_module():
    >       testdb.teardown()

    bigfile/tests/test_filezodb.py:58:
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    self = <wendelin.lib.testing.TestDB_ZEO object at 0x7fb9c0216350>

        def teardown(self):
            # close connections that test code forgot to close
            for connref, tb in self.connv:
                conn = connref()
                if conn is None:
                    continue
                if not conn.opened:
                    continue    # still alive, but closed
                print("W: testdb: teardown: %s left not closed by test code"
                      "; opened by:\n%s" % (conn, tb), file=sys.stderr)

                db = conn.db()
    >           stor = db.storage
    E           AttributeError: 'DB' object has no attribute 'storage'

    lib/testing.py:217: AttributeError

The fix is simple - don't use db.storage at all, because it is not actually used in that code.