BIND 10 #2205: introduce a "data source configurator" thread in auth

[BIND 10 Development]

#2205: introduce a "data source configurator" thread in auth
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  accepted
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121023
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 trac2205 is ready for review.

 It depends on #2332, which is also under review, but based on the
 review discussion, I believe the end result of #2332 doesn't affect
 the fundamental design of this branch, and so review of this branch
 can be started now.

 The diff to be reviewed is the result of 'git diff 4629279'.  The
 commits before this is to incorporate a snapshot version of #2332 and
 should be ignored for this review.

 I first suggest reading datasrc_clients_mgr.h and its comments.  It
 describes general design in some detail, and also has most of the
 actually implementation.

 There's one unrelated cleanup: b4ec1b3.  It's totally unrelated but
 something I just happened to notice and could be easily fixed.  So I
 did it here.

 Regarding the design: to be honest I forgot the intermediate comment
 by Michal at http://bind10.isc.org/ticket/2205#comment:5 and have
 completed the current implementation; now that I have a specific
 design and implementation maybe I'm already biased, but after thinking
 about it for a while I decided to keep the current design.  I see
 advantages of the suggested way: it can be more generic, but at the
 same time we need to define specific work functors in the main thread
 side, which means to test them we need to expose them more visibly.  I
 wanted to keep these details as much as possible, and preferred the
 current way where detailed work logic is hidden in an essentially
 private class.  But in any case, we don't have much real work logic
 yet, so if someone wants to revise this part with the functor approach
 in #2210 or #2212, I don't oppose to that just because the initial
 implementation doesn't adopt it.

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