BIND 10 #2836: update in-memory zone loading so it can work with shmem segment

[BIND 10 Development]

#2836: update in-memory zone loading so it can work with shmem segment
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  UnAssigned
            Priority:  high          |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130514
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => UnAssigned
 * status:  accepted => reviewing


Comment:

 Hello

 I've implemented the part in ZoneDataUpdater. However, there are two
 catches:

 Replying to [ticket:2836 jinmei]:
 > (according to my previous experiment) Most of the current
 > implementation is sufficiently generic, so this task shouldn't be that
 > difficult.

 Many places don't expect the zone_data_ to change after being passed to
 the updater. One example is the tests, that are updated in this branch.
 But from fast look, there are others. I'd like to have review of this
 first, then do the rest (either in this ticket, or some other).

 > There may be some other places that need the same trick (this was the
 > only case in my experiment, but I may have missed something).

 I found yet another, but I rearranged the code a little, so everything is
 hidden inside single call, which is retried on the segment growth.

 It also retries multiple times if there wold be multiple attempts to grow
 the segment.

 > And also consider calling `MemorySegment::shrinkToFit()` in zone
 > writer's cleanup() (for now `ZoneWriterLocal`, but I guess we'll
 > cancel subclass the writer class; it would work independently from the
 > memory segment type).  This will help minimize the extra memory space
 > overhead after loading/replacing the zone.

 This is the second catch. This is tricky, as the shrinkToFit is available
 only on the mapped memory segment, not on the abstract base one, so it
 would be breaking the abstraction if it tried to do that. And there's no
 possibility how to put the mapped segment into the zone writer anyway, as
 the local zone table segment creates only local memory segment, so we
 can't test it. Also, I'm not sure if it is the best place to handle that,
 shrinking after loading each zone. Or will we have single zone in each
 file?

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