BIND 10 #2091: use encoded name data in RBNode

[BIND 10 Development]

#2091: use encoded name data in RBNode
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  accepted
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120731
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Please review trac2091a (don't forget 'a').

 It turns out I needed some preparation work for the main subject of
 this ticket, and that part became already pretty big, so I think it's
 better to get that part reviewed first.

 This preparation work itself consists of two independent features:
 - use `MemorySegment` for `RBTree` and its nodes: changes 2e99938
   and d6b44e0
 - updates to `LabelSequence`: the rest of the branch.

 The first part of diff is quite big, but changes to the tests are
 basically straightforward adjustments due to interface change.

 The `LabelSequence` updates consist of two things:
 - make sure the NONE result of compare() has non 0 ordering.  I've
   also noticed the original implementation was unnecessarily
   complicated, so I tried to make it much simplified.  I've clarified
   the semantics by updating the documentation.  These changes are up
   to f5f665b.
 - introduce serialization/deserialization of `LabelSequence`.  the
   most critical issue was that the existing API doesn't allow to
   construct the label sequence from raw data if the sequence is non
   absolute.  On looking into it, I also thought it would make more
   sense to make the serialized data more opaque for the client side,
   rather than let them handle name/offset data directly.  So I revised
   the interface by introducing a new serialization method and
   constructor from it, and clean up the old ones (I'm sorry for
   dropping the efforts spent on them...when we see specific needs for
   them we can restore these interfaces.  Until then I think it's
   better to keep the class concise with things we know we need).
   Changes 9cc4ac5 and 5b7ac01 are for the new interface.  ecd6c30 is
   just to cleanup the old ones.  So it's probably easier to review if
   you separate the last chunk from others.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2091#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development