Remove _p_independent mechanism

[Stefan H. Holek]

See http://mail.zope.org/pipermail/zodb-dev/2007-July/011096.html

[Stefan]
BTrees.Length is used in many places to maintain the length of BTrees. Just the other day it was added to zope.app.container.btree. While I am happy about the speed improvements, I am concerned about the fact that BTrees.Length declares itself _p_independent. I'd like some clarification about what happens in a conflict resolution situation, when the Length is _p_independent but the BTree itself is not. I *think* that with MVCC this means a read-conflict will reset the BTree, but not it's Length.

All I could google up is this from 2004: http://mail.zope.org/pipermail/zodb-dev/2004-April/007269.html

Now, do we need another Length class or is BTrees.Length just fine and dandy?

[Jim]
Thanks for bringing this up. Looking at this again, I fail to see the point of _p_independent in the presence of MVCC. The API was originally added to avoid read conflicts when we read dirty data. With MVCC we no-longer read dirty data. Unless I'm missing something, I'd like to just drop the concept altogether.

Would you mind creating a launchpad issue to that effect?