On Python 2 and Mac OS X, checkFlushAfterTruncate was failing.

Changed to always empty the file pool.  I doubt that just flushing on
Python 2 was much of an optimization, and ... Python 2. :)

Incididentally, should make the Py26 winbot happy too, until we can get
it disabled.

Fixed test failure introduced in pull-request 51

Fix possible data corruption after FileStorage is truncated to roll back a transaction

The PR depended on system time being UTC.

Multi-threaded IO support, which is new to ZODB 3.10, allows clients to read
data (load & loadBefore) even after tpc_vote has started to write a new
transaction to disk. This is done by using different 'file' objects.

Issues start when a transaction is rolled back after data has been appended
(using the writing file object). Truncating is not enough because the FilePool
may have been used concurrently to read the end of the last transaction:
file objects have their own read buffers which, in this case, may also contain
the beginning of the aborted transaction.

So a solution is to invalidate read buffers whenever they may contain wrong
data. This patch does it on truncation, which happens rarely enough to not
affect performance.

We discovered this bug in the following conditions:
- ZODB splitted in several FileStorage
- many conflicts in the first committed DB, but always resolved
- unresolved conflict in another DB
If the transaction is replayed with success (no more conflict in the other DB),
a subsequent load of the object that could be resolved in the first DB may, for
example, return a wrong serial (tid of the aborted transaction) if the layout
of the committed transaction matches that of the aborted one.

The bug usually manifests with POSKeyError & CorruptedDataError exceptions in
ZEO logs, for example while trying to resolve a conflict (and restarting the
transaction does not help, causing Site Errors in Zope). But theorically,
this could also cause silent corruption or unpickling errors at client side.

Cleanup dependencies, remove ZEO leftovers

- remove now useless `zdaemon` dependency
- remove ZEO documentation
- update dependency list in README

patch time.time in historical_connections to avoid windows failures; fix race condition in pool.availableGC

* patch time.time in historical_connections to avoid windows failures.

* Also use a mock version of datetime.datetime.utcnow.

We can't patch the method in-place because it's an extension type.

* synchronize sleep with time

* increment by less than the pool timeout to avoid a race condition.

* Avoid mutating the dict as we iter over it.

Seen in Python 3.4 tests:

File "/home/travis/build/zopefoundation/ZODB/src/ZODB/historical_connections.txt", line 263, in historical_connections.txt
Failed example:
    conn = db.open()
Exception raised:
    Traceback (most recent call last):
      File "/opt/python/3.4.2/lib/python3.4/doctest.py", line 1324, in __run
        compileflags, 1), test.globs)
      File "<doctest historical_connections.txt[0]>", line 1, in <module>
        conn = db.open()
      File "/home/travis/build/zopefoundation/ZODB/src/ZODB/DB.py", line 761, in open
        self.historical_pool.availableGC()
      File "/home/travis/build/zopefoundation/ZODB/src/ZODB/DB.py", line 277, in availableGC
        for key, pool in self.pools.items():
    RuntimeError: dictionary changed size during iteration

Do3cc fix for45 master

Nested connections try to clean up themselves multiple
times. This does not work

Drop support for Python 2.6 / 3.2.

3.2 is no longer supported by our packaging / CI tools.

2.6 is long out-of-support from Python devs.

Cleanup tox.ini and .travis.yml as mentioned in #42 (and Python 3.5)

- (Both) Remove repetition of deps. Only install tests_require deps
  explicitly. The previous comment in tox.ini about eggs in the
  working directory doesn't apply, per @mgedmin.
- Setup Travis to use the local wheel cache for faster install times.

See http://zestreleaser.readthedocs.org/en/latest/versions.html.

Make zodbpickle non-optional. 

(IIRC a bug in python-modernize causes duplicate future imports)

Use PEP-426 environment markers

Any attempts to use platform_python_implementation or
implementation_name result in an "Invalid environment marker" error.

Any attempts to use >= to compare python_version result in an "Invalid
environment marker" error.

Augh documentation for all of this is painfully suboptimal.

Should fix #36