BIND 10 #2163: [meta] use signed RRset "as is" in Message

[BIND 10 Development]

#2163: [meta] use signed RRset "as is" in Message
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  UnAssigned
            Priority:  medium        |                       Status:  new
           Component:  libdns++      |                    Milestone:  New
           Sensitive:  0             |  Tasks
         Sub-Project:  DNS           |                     Keywords:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |  scalable inmemory
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 I propose changing the way of handling "signed `RRset`s", ie.,
 `RRset`s that are associate with RRSIG `RRsets` in the libdns++
 `Message`, especially in the toWire() rendering.

 Right now, we add a signed `RRset` by `Message::addRRset()` with
 the `sign` argument being true, and the `addRRset` method
 extracts the RRSIG by `getRRsig()` and inserts it into the internal
 vector.

 This behavior is suboptimal for the revised in-memory data source
 architecture, because `ZoneFinder::find()` would have to dynamically
 create two `RRset`s every time.  Also, as we introduced the abstract
 concept of "signed `RRset`", I personally believe it's cleaner if the
 user of that concept (such as `Message`) can be agnostic about it as
 much as possible, and let the `RRset` itself decide what to do
 depending on whether it's signed or not.

 Based on this observation and opinion I'm going to create a few
 development tickets to change the behavior.  In essence it shouldn't
 be very complicated updates, but we'll need to update a certain amount
 of code because it will probably affect many test cases.

 This work is related to the "one non trivial open issue" mentioned
 in #2098.

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