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

[BIND 10 Development]

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

Comment (by jinmei):

 Replying to [comment:1 vorner]:
 > Looking at this ticket, I wonder, will the memmgr read all zones from
 the configuration and prepare them, or will it work on-demand ‒ auth asks
 „I'd like a zone example.org loaded from here“ and it would do the load
 then?
 >
 > If the second, the load-all method could be sending of the request.

 What I'm currently envisioning is the first one.

 If we have this config:
 {{{
 "IN": [{
     "type": "sqlite3",
     "params": {"database_file": "/usr/local/var/bind10/zone.sqlite3"},
     "cache-zones": ["example.org", "example.com"],
     "cache-enable": true,
     "cache-segment-type": "mapped",
     "cache-segment-params": {
       "mapped-file-base": "/usr/local/var/bind10/zone.mapped"
     }
 }]
 }}}

 The `ClientList` for the auth server first tries to prepare
 `ZoneTableSegment` using a mapped memory segment, but notices it's not
 ready yet, so somehow mark the property of the corresponding client as
 something like "pending segment map" (see #2835 for properties).
 "cache-zones" is meaningless for this client list (although it could
 be used for some validation at the time of mapping).

 When the auth server completes building the `ClientList`, it gets the
 list of client's properties (using the #2835 interface), and sends a
 "get segment info" (or something) command to the memmgr for the
 clients that have pending segments.

 Meanwhile, memmgr starts up with the same config, but it actually
 builds the memory image for the "cache-zones" for each client, and
 maintains the relationship between clients and mapped files (e.g.
 for "sqlite3" client, /usr/local/var/bind10/sqlite3-zone.mapped, etc).

 When memmgr receives a "get segment info" command from other module,
 it responds to it with the mapping information.

 When auth receives its response, it updates the pending client with
 the given information.  At that point the corresponding "mapped memory
 segment" will be ready for use, and the in-memory cache will start
 working.

 (This is a simplified scenario; we'll also need to consider some
 exceptional cases and error handling, but they are omitted here).

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