Fix issue with mro in zodb

[do3cc]

@mgedmin Thanks for point me to the failing zodb tests.
I am not happy with this solution, but checking for the mro attribute failed, probably because of the python trick to make __ private, and isinstance(layer, type) also failed, maybe because of old style layer classes.
I was also wondering, if it is legal to have an object as a layer, but the docs don't say.
I manually tests zodb with 3.4 and this change, and my tests then ran through

[mgedmin]

Layers don't have to be classes. They're objects with a __bases__ attribute listing base layers. I've been confused by this in the past.

1. We should have an explicit test of this use-case.
2. I fear layer.__class__.__mro__ is wrong and we need to do a manual traversal of layer.__bases__.

[do3cc]

I fear it must be both classes and mro
I fear I fell into a deep pit

[do3cc]

I have reviewed code and docs a bit more. zope.testrunner keeps it simple for itself.
They do not state if a layer has to be a class, but they state that Layers can be extended giving an example of extending classes via subclassing. http://docs.zope.org/zope.testrunner/index.html#layers
In the implementation, base classes are looked up by going over the elements of the __bases__ property which is a python property. https://docs.python.org/2/library/stdtypes.html#special-attributes
Since it is not part of the zope.testrunner docs, I would say that it is reasonable to expect a layer to be a class like attribute. If one wants to fake it, depending on internal knowledge of how resolution works, one has to suck it up that a new patch release changes internal details and one has to provide a __mro__ method too now.
Sorting by mro is safe because layer setup is done breath-first. __mro__ works the same, mostly.

[mgedmin]

zope.testrunner's documentation says "Layers are generally implemented as classes using class methods" (emphasis mine), which can be read to imply that they don't have to be.

Martin Aspeli describes some downsides of using classes themselves as test layers in this email from 2010.

Some market research:

• ZODB uses an object instance as the layer.
• zope.app.testing.functional, uses an object instance as the layer.
• zope.app.wsgi uses object instances as the layer.
• plone.testing defines object instances to be used as test layers.
• gocept.selenium builds on top of plone.testing and therefore also uses object instances as test layers.

In short, I don't think zope.testrunner can afford to drop support of object instances as test layers (or require that everyone go implement a __mro__ property on their test layers) at this time, without a painful transition affecting many users.

I suggest that reimplementing the MRO algorithm inside zope.testrunner to compute the MRO from layer.__bases__ is the right thing to do. I volunteer to do it if nobody else steps forward. ;)

[do3cc]

Just for the record, I volunteered too. For reverting 4.4.5...

[mgedmin]

Oh my, this is a can of worms.

I'm now worrying about the implications of zope.testrunner not using the C3 MRO algorithm when running layer setup.

(AFAICS the optimal layer ordering solution that minimizes the total number of layer setUp/tearDown calls is NP-hard.)

[mgedmin]

#20 is my attempt to fix this by moving forwards rather than backwards. Review would be appreciated!

[mgedmin]

Fixed by #20.