BIND 10 #1614: in memory loader should be able to load RRSIGs correctly

[BIND 10 Development]

#1614: in memory loader should be able to load RRSIGs correctly
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  major         |                    Milestone:  Next-
           Component:  data source   |  Sprint-Proposed
           Sensitive:  0             |                     Keywords:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 We need to think about several things:

 - Correctly distinguish RRSIGs that have different covering types
 - How to store RRSIGs: whether storing them in the same table as other
   ordinary types of RRs or attaching them to the corresponding covered
   RRsets at load time.  In the former case, find() needs to be able to
   construct returned RRsets with RRsigs on the fly - see also #1552.
   In the latter case, in general we need to be able to handle RRSIGs
   are passed to the loader before the covered RRsets.
 - const-ness: RRsets are passed to the loader (and currently
   maintained in the data source) as const data.  So we cannot simply
   attach RRSIGs via addRRsig() unless we break the const or copy the
   original RRset every time.

 My current suggestion is:

 - Attach RRSIGs at load time because it will make lookup performance
   more efficient.  Ignore the reverse ordering for now - as long as
   the source is generated by something like dnssec-signzone this
   shouldn't happen.
 - As for const-ness, intentionally break cost at load time (i.e use
   const_cast and call addRRsig) for now.  This is ugly and bad
   practice, but in practice the caller of the in-memory loader would
   normally transfer the ownership of the RRsets (this is the case for
   b10-auth), so it actually won't result in inconsistency.  In future,
   we need to revise the internal representation anyway, not storing
   the data in the form of high level RRset objects to reduce memory
   footprint, and we should be able to solve the issue more cleanly at
   that point.

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