BIND 10 #1607: define ZoneFinder::findAdditional() and implement its default version

[BIND 10 Development]

#1607: define ZoneFinder::findAdditional() and implement its default version
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120320
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  auth   |
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:13 vorner]:

 > > Would you like to introduce the change now, or should it go to a
 > > separate ticket?
 >
 > Hmm, I don't really want to slow the ticket down too much, but it would
 be nice to have all the interface changes at once, if at all possible. So,
 if it isn't too much work, I'd prefer it now.

 On thinking about it further, I'd like to propose deferring this after
 the cleaner abstraction (which would also be deferred to post #1608)
 and #1747.  Depending on the former, we may change how the application
 gets the result (with the pure abstract model it will need to get the
 resulting RRset, etc, via an accessor method, not just by referring to
 a const member object).  Also, #1747 will give a more concrete view on
 how the application wants to get information from the context.

 If this is okay I'll create a ticket and keep this branch intact.

 > Well, my original idea was to have the abstract base class without any
 guts. Then there'd be a default base class (something like the current
 version), that would be used if someone wanted no customization or just a
 partial customization. And if some datasource felt really brave, it could
 go and do full customization on top of the very abstract one.
 >
 > I don't think it makes sense to do anything too complicated because of
 the vector, if they'll be reused, an empty vector that is just sitting
 there is not a big problem.

 Okay, not fully thought about it, but this model seems quite clean to
 me.  In any case, I propose to defer this work to the separate ticket
 I suggested above.

 If these plans are acceptable, I think the branch is now okay for
 merge with creating deferred tickets.  If misunderstand it or if you
 don't agree with the plan please let me know.

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