BIND 10 #2094: Define and implement RDATA field specs

[BIND 10 Development]

#2094: Define and implement RDATA field specs
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |                       Status:  new
            Priority:  medium        |                    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             |  scalable inmemory
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 As suggested in
 http://bind10.isc.org/wiki/InMemoryZoneDesign#a4.1.RDATAfieldspecification.
 I also found `RdataEncodeSpec` would need a field for the number of
 variable length fields.

 We should define some major RR types, at least up to type 48
 (DNSKEY).  But most of them can be just single-field opaque (varlen)
 DATA, so it shouldn't be that a big task.

 We also need to define a lightweight interface so that we can get
 `RdataEncodeSpec` for a given type.

 One note: The RDATA spec cannot only be determined by type as there
 are some class specific types (like A RDATA).  But in practice the
 vast majority of the case we should only see the IN class.  So we need
 to make it optimize for IN while it can be generic.  I skipped that
 consideration in my experiments, but in the real task we should take
 into this account (or at least keep the interface generic and do
 assert() if it's not IN).

 No dependency.  Can start anytime.

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