BIND 10 #2833: refactor relationship between datasrc::ClientList and ZoneTableSegment

[BIND 10 Development]

#2833: refactor relationship between datasrc::ClientList and ZoneTableSegment
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  medium                             |              Keywords:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
               CVSS Scoring:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  shared memory data source          |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
 subtask of #2830.  depend on #2832.

 not directly related, but IMO will be a helpful cleanup for later
 development.

 The basic motivation is to make `ClientList` (and `InMemoryClient`)
 segment-type agnostic as much as possible.

 Feature wise what we'll do is

 - create separate zone table segment for each client
 - pass specific config (maybe reorganize it) to
   `ZoneTableSegment::create`.  specifically, we pass
   cache-segment-type, cache-segment-params, and cache-zones.
   in case of `MasterFiles`, cache-zones should be created from
   its own param.  also pass "load param", which is, in case of
   `MasterFiles`, its own param (zone name to file map)
 - also pass a `GetLoadAction` functor to create (we need to extend
   it).  which would look like:
 {{{
 typedef boost::function<LoadAction(const Name& zone_name, ConstElementPtr
 param)> GetLoadAction;
 }}}
   For `MasterFiles`, param will be ignored, and something similar to
   `loadZoneDataFromFile` will be used.  For others, the returned
   functor would encapsulate the underlying data source client so it
   can create an iterator on actual load.
 - if necessary (e.g. in case of local) the actual zone table segment
   implementation iterates over the cache-zones, and call the given
   GetLoadAction with the name and "load param" part of the config.
 - extend the zone table segment class adding the "loadAll" method
   (virtual).  the behavior differs depending on the characteristics of
   the segment.  if necessary (e.g. in case of local) the actual zone
   table segment implementation iterates over the cache-zones, and call
   the given GetLoadAction with the name and "load param" part of the
   config. It then uses the `ZoneWriter` with the returned `LoadAction` to
   actually load the data into the segment.  But in the case of "read
   only" shared memory/mapped segment, it will do nothing at this
   point.  the "load" will be a mapping operation that will happen
   later (information given by the memmgr).

 Also, cache-zones list and load params may be kept inside the table
 segment in case of reload.

 The main point of these changes is to move the decision of whether to
 actually load from `ClientList` to the segment manager.  It will also
 allow (later) to remove file lists from `MemoryClient`.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2833>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development