Fixed to use a separate Random instance.

----------

- BTrees (and TreeSets) kept references to internal keys.
  https://bugs.launchpad.net/zope3/+bug/294788

- BTree Sets and TreeSets don't support the standard set add method.
  (Now either add or the original insert method can be used to add an
  object to a BTree-based set.)

setuptools installed.

https://bugs.launchpad.net/zodb/+bug/185066

The fix didn't go far enough and a fix that would go far enough would
be too risky this late in the 3.9 beta cycle.  This will probably need
to wait till 3.10.

  Certain ZEO server errors could cause a client to get into a state
  where it couldn't commit transactions.
  https://bugs.launchpad.net/zodb/+bug/374737

  Savepoint blob data wasn't cleaned up after a transaction abort.
  https://bugs.launchpad.net/zodb/+bug/323067

  When committing transactions involving blobs to ClientStorages with
  non-shared blob directories, a failure could occur in tpc_finish if
  there was insufficient disk space to copy the blob file or if the
  file wasn't available.  https://bugs.launchpad.net/zodb/+bug/224169

Now link/copy file when storeBlob is called.

  Objects defining _p_deactivate methods that didn't call base methods
  weren't loaded properly. https://bugs.launchpad.net/zodb/+bug/185066

for objects that don't use slots, which are the vast majority of
persistent objects.

while cleaning up removed blob files.

Also refactored the code slightly for clarity.

(https://bugs.launchpad.net/zodb/+bug/400775)

Also, stop producing legacy PersistentMapping state, while still
accepting it.

Simplified the file-storage configuration a bit.  Eliminated
duplication of defaults between the Python and ZConfig interfaces.

- Fixed vulnerabilities in the ZEO network protocol that allow:

CVE-2009-0668 Arbitrary Python code execution in ZODB ZEO storage servers
  CVE-2009-0669 Authentication bypass in ZODB ZEO storage servers

- Limit the number of object ids that can be allocated at once to
  avoid running out of memory.