Implement Reversible interface about btrees HOT 1 OPEN

I would like to tackle this issue. As discussed in #133, that should need to modify to bucket state to add a pointer to the previous bucket.

Assuming I can provide an acceptable patch for this feature, I would like to discuss with you the strategy to get it merged, as the compatibility issue might be tricky. I suggest this roadmap:

• BTrees v4: cannot deal with states containing the prev pointer;
• BTrees v5: can read (but ignore) the prev pointer, do not write it in the state;
• BTrees v6: reads and write the prev pointer in the bucket state, use fallback mechanisms when prev is not in the state.

I see several benefits with this strategy:

• In terms of project management, this separation can make things clear:
  • v4 buckets can safely be handled by v5, and vice-versa;
  • v5 buckets can safely be handled by v6, and vice-versa;
  • v4 buckets can safely be handled by v6;
  • v6 buckets cannot be handled by v4, so you should not have projects using v4 and v6 plugged to the same database.
• No migration is needed as BTrees v6 will still be able to manage buckets states without the prev pointer. Using reverse features simply will be slow as we will need to calculate the previous bucket each time we need to access it. Maybe we can raise a warning when this case appear?
• This transitional v5 can be used to backport fixes and patches from v6 if some people to stay a bit more time in v5.

What do you think?

from btrees.