* FileStorage: fix data corruption when using restore after multiple undos

The case of a history like this:
 - T0 initialize an object in state 0
 - T1 modifies object to state 1
 - T2 modifies object to state 2
 - T3 undo T2 and T1, bringing back to state 0
 - T4 modified object to state 3
 - T5 undo T4, bringing back object to state 0

was not correct after `restore`: the state is 1 instead of the expected 0.

This is because T3 contains two data records:
 - an undo of T2, with a backpointer to the data of state 1
 - an undo of T1, with a backpointer to the data of state 0
When restoring T5 (the undo of T4), the transaction is made of one data
record, with a backpointer that is copied from the backpointer from T3,
but this uses backpointer from the first record for this object, which
is incorrect, in such a case where there is more than one backpointer
for the same oid, we need to iterate in all data record to find the
oldest version.
Co-authored-by: Kirill Smelkov <kirr@nexedi.com>

When verification failed, repozo prints a message on standard error,
but the program always exits with a return code indicating a success.
In case of error it's more natural to exit with an error return code.

Co-authored-by: Jens Vagelpohl <jens@plyp.com>
Co-authored-by: Michael Howitz <icemac@gmx.net>

* Bumped version for breaking release.

* Drop support for Python 2.7, 3.5, 3.6.

---------
Co-authored-by: Jens Vagelpohl <jens@plyp.com>

The newt db project appears to be dead; the domain name now leads to a domain parking website.

positive_id was added in 2004 in f7b96aea (ZODB.utils grows a new
function positive_id(), which returns the id() of an object as a
non-negative integer ...) to workaround change in behaviour Python2.3 ->
2.4 for `'%x' % <negative-number>`. And nowdays `positive_id` is used
only in one place in Connection.__repr__ to mimic approximately what
Python already gives for a default __repr__ out of the box.

On https://github.com/zopefoundation/ZODB/actions/runs/5067242751/jobs/9098062772
we recently hit

    ZODB.POSException.InvalidObjectReference: <unprintable InvalidObjectReference object>

for the following code:

    if self._jar.get_connection(database_name) is not obj._p_jar:
        raise InvalidObjectReference(
            "Attempt to store a reference to an object from "
            "a separate connection to the same database or "
            "multidatabase", self._jar, obj,
        )

    ( https://github.com/zopefoundation/ZODB/blob/5.8.0-24-g8a7e3162d/src/ZODB/serialize.py#L366-L371 )

for which the "unprintable ..." part is produced by `Lib/traceback.py`
who tries to do `str(ex)` and returns `unprintable ...` if that str
failed:

    https://github.com/python/cpython/blob/v3.8.16-18-g9f89c471fb1/Lib/traceback.py#L153-L157

Since one of the reasons for that failure might have been a bit
non-trivial code and assert in positive_id, let's remove it and rely on
builtin python behaviour for Connection repr.

repr for Connection:

before this patch:

    <Connection at 0x7fef09989d10>

after this patch:

    <ZODB.Connection.Connection object at 0x7fef09989d10>

/reviewed-by @dataflake, @d-maurer 
/reviewed-at https://github.com/zopefoundation/ZODB/pull/384

The last usage of WarningsHook was removed in 2011 in f1b04dd8 (Lots of
code cleanups.). And when we need to capture warnings there is
`warnings.catch_warnings` that is available out of the box from stdlib
on both py2 and py3.

`racetest` improvement

- Rename `TestGroup` -> `TestWorkGroup`. I originally named it as just
  WorkGroup similarly to sync.WorkGroup in pygolang, but later added
  "Test" prefix to highlight the difference that this class manages
  working group of threads that take part in tests, instead of group of
  arbitrary threads. However in that process I dropped the "Work" part
  which turned the name to be somewhat ambiguous: it is not clear whether
  "TestGroup" is a group of threads serving one test, or a group of
  separate tests without any relation to threading. To remove the
  ambiguity let's restore the "Work" in the name so that both "Test" and
  "WorkGroup" are there.

- Review test_racetest.py a bit:

  * make it a bit more robust by increasing "ok" timeout from 0.1s to 10s.
    in my experience 0.1s is too little and will regularly hit "timeout"
    when CI machines are overloaded. I'm still somewhat uncomfortable
    with 0.1s timeout we left in tests that exercise timeout handling,
    but let's leave it as is for now and see how it goes.

  * add test for cases when only one thread fails out of many, and when
    several threads fail too.

  * minor cosmetics.

- spellcheck.

Add the thread name to failure reports due to exceptions.
First update `TestGroup.threadv` before the thread is started.

- Factor common logic to spawn and run group of test threads into
  TestGroup. This way the extra checks and robustness improvements, that
  Dieter just added to check_race_external_invalidate_vs_disconnect,
  become available to all tests in racetest module.

  Rework moved code so that nwork is not fixed beforehand and test threads
  can be added dynamically.

- fix waiting logic in Finished:
  * on py2 Condition.wait does not return True/False as it does on py3 -
    we need to manually inspect the state.
  * fix race for when wait is called with already met condition:
    previously in such case it was waiting indefinitely and reporting
    failure on timeout

- rename Finished to well-established concept of WaitGroup and adjust
  its interface accordingly (see
  https://pkg.go.dev/sync#WaitGroup,
  https://lab.nexedi.com/nexedi/pygolang/blob/master/golang/sync.py and
  https://lab.nexedi.com/nexedi/pygolang/blob/39dde7eb/golang/sync.cpp#L153-200)

- no need to wrap try/except with additional try/finally, as
  try/except/finally works out of the box.

Corrected a few typos

Fix `racetest` problems

treat failure for a test thread to finish as a test failure