There are small typos in:
- docs/articles/ZODB2.rst
- src/ZODB/Connection.py
- src/ZODB/FileStorage/fsdump.py
- src/ZODB/cross-database-references.rst
- src/ZODB/tests/testblob.py

Fixes:
- Should read `committed` rather than `commited`.
- Should read `resetting` rather than `reseting`.
- Should read `debugging` rather than `debuggin`.
- Should read `constructor` rather than `contructor`.

make blob test `commit_from_wrong_partition` more robust

See previous commit for context: which had to fix
commit_from_wrong_partition this way because without `logger.disabled =
False` logging could not produce its output under Python 3.6.

Discussion1: https://github.com/zopefoundation/ZODB/pull/360#pullrequestreview-936832062
Discussion2: https://github.com/zopefoundation/ZODB/pull/360#issuecomment-1093710722

The blob test `commit_from_wrong_partition` makes use of the logger `ZODB.blob.copied`.

In some cases, this test fails not because the ZODB did something wrong but because the logger is disabled.

At least under Python 3.6, `logging.fileConfig` (and likely all other functions configuring the logging system) disables by default all existing loggers. If logger `ZODB.blob.copied` is already created at that time (i.e. if `ZODB.blob` has been imported), it gets disabled.

The PR adds `logger.disabled = False` to the test `commit_from_wrong_partition` to let it work correctly in those situations.

https://github.com/zopefoundation/ZODB/commit/b6f4cd17cd186cb36025aef44e1cd02934d4fb07

* Config with pure python
* Lint the code.
* Add support for Python 3.9 and 3.10.

Add support for Python 3.9 and 3.10.

Fix `TypeError: can't concat str to bytes` when running fsoids.py script with Python 3.

Closes #350

fsdump/fsstats improvements

Define the official expansion of "ZODB"

Switch from Travis CI to GitHub Actions for testing

As suggested by @d-maurer:

https://github.com/zopefoundation/ZODB/pull/345#issuecomment-822188305
https://github.com/zopefoundation/ZEO/issues/168#issuecomment-821829116

/reviewed-on https://github.com/zopefoundation/ZODB/pull/345

For ZEO this data corruption bug was reported at
https://github.com/zopefoundation/ZEO/issues/155 and fixed at
https://github.com/zopefoundation/ZEO/pull/169.

Without that fix the failure shows e.g. as follows when running ZEO test
suite:

    Failure in test check_race_load_vs_external_invalidate (ZEO.tests.testZEO.BlobAdaptedFileStorageTests)
    Traceback (most recent call last):
      File "/usr/lib/python2.7/unittest/case.py", line 329, in run
        testMethod()
      File "/home/kirr/src/wendelin/z/ZODB/src/ZODB/tests/BasicStorage.py", line 621, in check_race_load_vs_external_invalidate
        self.fail([_ for _ in failure if _])
      File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
        raise self.failureException(msg)
    AssertionError: ['T1: obj1.value (7)  !=  obj2.value (8)']

Even if added test is somewhat similar to
check_race_loadopen_vs_local_invalidate, it is added anew without trying
to unify code. The reason here is that the probability to catch load vs
external invalidation race is significantly reduced when there are only
1 modify and 1 verify workers. The unification with preserving both
tests semantic would make test for "load vs local invalidate" harder to
follow. Sometimes a little copying is better than trying to unify too
much.

For the test to work, test infrastructure is amended with
._new_storage_client() method that complements ._storage attribute:
client-server storages like ZEO, NEO and RelStorage allow several
storage clients to be connected to single storage server. For
client-server storages test subclasses should implement
_new_storage_client to return new storage client that is connected to
the same storage server self._storage is connected to.

For ZEO ._new_storage_client() is added by https://github.com/zopefoundation/ZEO/pull/170

Other client-server storages can follow to implement ._new_storage_client()
and this way automatically activate this "load vs external invalidation"
test when their testsuite is run.

Contrary to test for "load vs local invalidate" N is set to lower value (100),
because with 8 workers the bug is usually reproduced at not-so-high iteration
number (5-10-20).

/cc @d-maurer, @jamadden, @jmuchemb
/reviewed-on https://github.com/zopefoundation/ZODB/pull/345

Add test that exercises open vs invalidation race condition that, if
happen, leads to data corruption. We are seeing such race happening on
storage level in ZEO (https://github.com/zopefoundation/ZEO/issues/166),
and previously we've seen it also to happen on Connection level
(https://github.com/zopefoundation/ZODB/issues/290). By adding this test
to be exercised wrt all storages we make sure that all storages stay
free from this race.

And it payed out. Besides catching original problems from
https://github.com/zopefoundation/ZODB/issues/290 and
https://github.com/zopefoundation/ZEO/issues/166 , this test also
discovered a concurrency bug in MVCCMappingStorage:

    Failure in test check_race_open_vs_invalidate (ZODB.tests.testMVCCMappingStorage.MVCCMappingStorageTests)
    Traceback (most recent call last):
      File "/usr/lib/python2.7/unittest/case.py", line 329, in run
        testMethod()
      File "/home/kirr/src/wendelin/z/ZODB/src/ZODB/tests/BasicStorage.py", line 492, in check_race_open_vs_invalidate
        self.fail(failure[0])
      File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
        raise self.failureException(msg)
    AssertionError: T1: obj1.value (24)  !=  obj2.value (23)

The problem with MVCCMappingStorage was that instance.poll_invalidations
was correctly taking main_lock with intention to make sure main data is
not mutated during analysis, but instance.tpc_finish and
instance.tpc_abort did _not_ taken main lock, which was leading to
committed data to be propagating into main storage in non-atomic way.

This bug was also observable if both obj1 and obj2 in the added test
were always loaded from the storage (added obj2._p_invalidate after
obj1._p_invalidate).

-> Fix MVCCMappingStorage by correctly locking main MVCCMappingStorage
instance when processing transaction completion.

/cc @d-maurer, @jamadden, @jmuchemb
/reviewed-on https://github.com/zopefoundation/ZODB/pull/345

buildout: Fix CI

/reviewed-on https://github.com/zopefoundation/ZODB/pull/346
/reviewed-by @d-maurer

Commit 75c703fc (Security fix documentation dependencies (#342)) changed
requirements for pygments from

    # pygments 2.6 stops the support for python2
    pygments<2.6

to

    # Silence dependabot claiming a security issue in older versions:
    pygments >= 2.7.4

However this broke CI for python2, as sphinx now fails to install:

    Collecting Sphinx
      Using cached Sphinx-1.8.5-py2.py3-none-any.whl (3.1 MB)
    ERROR: Could not find a version that satisfies the requirement pygments>=2.7.4 (from -r doc/requirements.txt (line 3)) (from versions: 0.5, 0.5.1, 0.6, 0.7, 0.7.1, 0.8, 0.8.1, 0.9, 0.10, 0.11, 0.11.1, 1.0, 1.1, 1.1.1, 1.2, 1.2.1, 1.2.2, 1.3, 1.3.1, 1.4, 1.5, 1.6rc1, 1.6, 2.0rc1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.3.0, 2.3.1, 2.4.0, 2.4.1, 2.4.2, 2.5.1, 2.5.2)
    ERROR: No matching distribution found for pygments>=2.7.4 (from -r doc/requirements.txt (line 3))
    The command "if [[ $TRAVIS_PYTHON_VERSION != pypy3* ]]; then pip install --upgrade --requirement doc/requirements.txt; fi" exited with 1.

(see e.g. https://travis-ci.com/github/zopefoundation/ZODB/jobs/499836548)

Try to fix that by bringing back requirement for `pygments < 2.6` on
python2.

It is not only py2 as build on py3 is also affected, e.g.

https://travis-ci.com/github/zopefoundation/ZODB/jobs/499826281

And even though Sphinx is going to be ready for newer docutils,
sphinx_rtd_theme requires docutils<0.17 for now:

https://github.com/readthedocs/sphinx_rtd_theme/blob/2026bb61ddf85a672141127b162d6f9181603725/setup.py#L119-L122

Else it is failing as:

    Got j1m.sphinxautozconfig 0.1.0.
    Getting distribution for 'sphinx_rtd_theme'.
    Got sphinx-rtd-theme 0.5.2.
    Version and requirements information containing docutils:
      Base installation request: 'Sphinx', 'docutils', 'ZODB', 'sphinxcontrib_zopeext', 'j1m.sphinxautozconfig', 'sphinx_rtd_theme'
      Requirement of sphinx_rtd_theme: docutils<0.17
      Requirement of j1m.sphinxautozconfig: docutils
      Requirement of Sphinx: docutils<0.17,>=0.12
    While:
      Installing sphinx.
    Error: There is a version conflict.
    We already have: docutils 0.17.1
    but sphinx-rtd-theme 0.5.2 requires 'docutils<0.17'.

(see e.g. https://travis-ci.com/github/zopefoundation/ZODB/jobs/499760337)

Suggested by @d-maurer.

Fix tiny issue with a remaining colon that was probably not deleted during updates of the README.

According to dependabot Pygment versions < 2.7.4 are vulnerable.
Updating to this version even though it should not be a problem with our static documentation.

Commit fc4c86e6 (Fix unbound local error when using the fsoids.py script
(#295)) wanted to refer to "issue 285", but put it as "issue 268" into
visible text.