Creating the utility cache can be slow for persistent objects that implement __hash__

[jamadden]

Over in https://github.com/zopefoundation/ZODB/issues/106, I describe how having persistent objects that implement custom __eq__ and __hash__ methods can be bad for perfomance.

Unfortunately, that's not just a theoretical concern. One of our large sites had such objects, and so the utility cache that was introduced in #48 turned out not to help us out as much as we hoped until we went through and found all the classes that implemented __hash__ and __eq__ and didn't need to, which turned out to be an annoying, time-consuming process.

While browsing other code, I was reminded that zope.keyreference is designed to work around this exact problem.

Now, zope.interface itself can't use zope.keyreference, but maybe it could expose enough hooks that subclasses could easily do so? (Subclasses such as our own BTree-based component registry for large sites.)

Of course it'd be really sweet if zope.interface could handle this automatically (copying some code from zope.keyreference for objects with a _p_oid and using a similar identity-based proxy for objects without it) but changing from equality to identity based semantics by default for purposes of utility subscribers is probably a non-starter. (Is it?)

Is this likely to be a common-enough issue that we can workaround it, or provide the way to do so? Or would my group have just been better off patching the internal implementation of _UtilityRegistration ?

I'm willing to provide the work to generalize or solve this however seems best if it's decided it should go here.