This fixes testBasicStore when run with MySQL backend, which started to fail
with commit 9eb06ff1 when -L runner option is
not used.

This is a first version with several optimizations possible:
- improve EventQueue (or implement a specific queue) to minimize deadlocks
- turn the RebaseObject packet into a notification

Sorting oids could also be useful to reduce the probability of deadlocks,
but that would never be enough to avoid them completely, even if there's a
single storage. For example:

1. C1 does a first store (x or y)
2. C2 stores x and y; one is delayed
3. C1 stores the other -> deadlock
   When solving the deadlock, the data of the first store may only
   exist on the storage.

2 functional tests are removed because they're redundant,
either with ZODB tests or with the new threaded tests.

- Make sure that errors while processing a delayed packet are reported to the
  connection that sent this packet.
- Provide a mechanism to process events for the same connection in
  chronological order.

Fix conflict handling after a successful store to a node being disconnected for having missed a transaction

- fail sooner in case of unresolvable conflict
- avoid OOM when there are many conflicts

Now that we do inequality comparisons between timestamps, the master must
use a monotonic clock, to avoid issues when the clock is turned back.
Before, the probability that time.time() returned again the same value was
probably negligible.

This optimizes the normal case, and handlers can now take specific action
when requests are cancelled because a connection is closed.

It was only used by the now removed HasLock.

It was disabled long time ago and NEO has evolved in such a way that the new
implementation will be completely different.

It's dead code, because 1 year after it was introduced, something else was
implemented to detect deadlocks immediately.

Anyway, it would be an unacceptable way to detect them.

It was failing when some .py files were not compiled.

100 is too small for tests like testBasicStore (MySQL) and testDelayedStore.

When receiving 1 byte, benchmarking shows no visible difference with values
between 4096 and 65536 for the buffer size. With higher values, it becomes
significantly slower.

On the other side, a 64k buffer is faster with bigger packets.
Time to run testBasicStore with MySQL:

            4096        65536
    real    0m51.115s   0m21.592s
    user    0m41.857s   0m13.540s
    sys     0m8.700s    0m2.687s

It started to fail with commit fd007f5d.