Cleanup.__del__() calls transaction.abort(). transaction.abort()
implicitly uses thread-local transaction manager. __del__ method is
called when the last reference to an object is dropped. If there is no
object cycles this can be more or less controlled.

However if an object with __del__ method is held by some other objects
forming a cycle, the __del__ method will be called only eventually
whenever that cycle is garbage-collected by GC. The garbage collection
can be ran from *whatever* thread which caused the GC.

If we leave cleanup local variable, a reference to it will be held in
frame's .f_locals, and if e.g. an exception is raised and even caught
a cycle will be created:

            exc_traceback
              |        ^
              |        |
              v     .f_localsplus
             frame

This is perfectly the situation which was outlined above - a cycle of
objects which will be freed only by GC and one of those objects
(.f_localsplus) reference `cleanup`. This way Cleanup.__del__ will be
called not strictly when REQUEST goes away but maybe a bit later if the
cycle stays alive more (and thus potentially aborting different next
transaction) and/or from another thread (and thus aborting unrelated
transaction).

The case was caught via analyzing strange messages in Zope logs on a
Wendelin system:

	Exception KeyError: (140574709077840,) in <bound method Cleanup.__del__ of <App.ZApplication.Cleanup instance at 0x7fd9f22f6830>> ignored

This turned out to be Wendelin.core's _ZBigFileH.on_connection_close()
trying to unregister itself from transaction manager it previously
registered to on ZODB connection open:

	https://lab.nexedi.com/nexedi/wendelin.core/blob/87bf4908/bigfile/file_zodb.py#L621
	https://lab.nexedi.com/nexedi/wendelin.core/blob/87bf4908/bigfile/file_zodb.py#L608

the transaction_manager being ThreadTransactionManager:

	https://github.com/zopefoundation/transaction/blob/bd26c334/transaction/__init__.py#L23
	https://github.com/zopefoundation/transaction/blob/bd26c334/transaction/_manager.py#L122

which implicitly keeps its instance variables in thread-local storage
(i.e. self.var is different for every thread), and so
transaction_manager.unregisterSynch() was removing _ZBigFileH instance
from a set different to where it was originally registered:

	https://github.com/zopefoundation/transaction/blob/bd26c334/transaction/_manager.py#L79

thus the error message, not to mention the further inevitable
desynchronization in between wendelin.core transaction manager

	https://lab.nexedi.com/nexedi/wendelin.core/blob/87bf4908/bigfile/file_zodb.py#L548

and ZODB transaction manager which can lead to all kind of corruptions.

----

So do not let `cleanup` variable to stay in the frame. This is simple
but not optimal fix. The good solution would avoid using __del__ at all
and track request lifetime explicitly via regular programming logic.

Explicitly require Manager role for `AltDatabaseManager`.

'bin/buildout -n' did not help.

That fixed the build for me locally.
Error on Travis:

$ bin/buildout
Getting distribution for 'zc.buildout<2.4.dev'.
While:
  Installing.
  Loading extensions.
  Getting distribution for 'zc.buildout<2.4.dev'.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "/home/travis/build/zopefoundation/Zope/eggs/zc.buildout-2.9.3-py2.7.egg/zc/buildout/buildout.py", line 2123, in main
    getattr(buildout, command)(args)
  File "/home/travis/build/zopefoundation/Zope/eggs/zc.buildout-2.9.3-py2.7.egg/zc/buildout/buildout.py", line 637, in install
    self._load_extensions()
  File "/home/travis/build/zopefoundation/Zope/eggs/zc.buildout-2.9.3-py2.7.egg/zc/buildout/buildout.py", line 1163, in _load_extensions
    newest=self.newest, allow_hosts=self._allow_hosts)
  File "/home/travis/build/zopefoundation/Zope/eggs/zc.buildout-2.9.3-py2.7.egg/zc/buildout/easy_install.py", line 913, in install
    return installer.install(specs, working_set)
  File "/home/travis/build/zopefoundation/Zope/eggs/zc.buildout-2.9.3-py2.7.egg/zc/buildout/easy_install.py", line 714, in install
    for dist in self._get_dist(req, ws):
  File "/home/travis/build/zopefoundation/Zope/eggs/zc.buildout-2.9.3-py2.7.egg/zc/buildout/easy_install.py", line 570, in _get_dist
    dist = self._env.best_match(requirement, ws)
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources/__init__.py", line 1040, in best_match
    dist = working_set.find(req)
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources/__init__.py", line 672, in find
    raise VersionConflict(dist, req)
VersionConflict: (zc.buildout 2.9.3 (/home/travis/build/zopefoundation/Zope/eggs/zc.buildout-2.9.3-py2.7.egg), Requirement.parse('zc.buildout<2.4.dev'))

If you use experimental.publishtraverse and try to call manage_pack,
it warns that the object (the manage_pack function) has no roles.
In strict mode it will fail.
This is an indication that the function *might* be available for anonymous users.
That is not the case here, but being strict seems good.

* Test that `str.format` checks the security for attributes that are accessed.

Part of PloneHotfix20170117.

This needs https://github.com/zopefoundation/AccessControl/pull/23
This was merged, but not released yet, so we add AccessControl to auto-checkout for now.

* AccessControl has a release, no need for auto-checkout anymore.

In functional doc tests you can apparently have a test case that has
no runTest method.  Until now the Testing package added a dummy
runTest method in that case, and set it to None.

But when this dummy runTest method gets called, you get an error:

  Error in test runTest (Testing.ZopeTestCase.ZopeTestCase.FunctionalTestCase)
  Traceback (most recent call last):
    File ".../lib/python2.7/unittest/case.py", line 329, in run
      testMethod()
  TypeError: 'NoneType' object is not callable

Simply importing Testing.ZopeTestCase.FunctionalTestCase in a new test
file may be enough to trigger this.

So this has something to do with the order in which tests are found.

I fixed it by making the dummy runTest method callable.

Apply plonehotfix 20170717 [2.13]

This applies PloneHotfix20170117.

Patch zope.interface to remove docstrings and avoid publishing.

From Products.PloneHotfix20161129.
Signed-off-by: Maurits van Rees <maurits@vanrees.org>

Don't copy items the user is not allowed to view. [2.13]

From Products.PloneHotfix20161129.

Add support for optional 'SameSite' cookie attribute

As described in the definition document by the ietf:
https://tools.ietf.org/html/draft-west-first-party-cookies-07

"The 'SameSite' attribute allows servers to assert that a cookie
ought not to be sent along with cross-site requests. This assertion
allows user agents to mitigate the risk of cross-origin information
leakage, and provides some protection against cross-site request
forgery attacks."

Revert "Optimize 'OFS.ObjectManager.__contains__' method"

It causes problems with ZCatalog indexes.
See https://github.com/zopefoundation/Zope/issues/69

This reverts commit 753683e3.

Quote variables in manage_tabs and manage_container to avoid XSS [2.13]

From Products.PloneHotfix20160830.

The 3.0 release of the project contains no code. It allows projects
to declare a dependency on it for forward compatibility with Zope 4.

Apply hotfix 20160419 rebased

From Products.PloneHotfix20160419.