BIND 10 #1457: use the difference normalizer in the DDNS module

[BIND 10 Development]

#1457: use the difference normalizer in the DDNS module
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  UnAssigned
                       Type:  task   |                Status:  reviewing
                   Priority:         |             Milestone:
  medium                             |  Sprint-20120612
                  Component:  DDNS   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:  DDNS   |  Estimated Difficulty:  3
        Add Hours to Ticket:  0      |           Total Hours:  22
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => UnAssigned
 * status:  assigned => reviewing
 * totalhours:  0 => 22


Comment:

 Okay, hmm, be warned: the diff for this branch is even larger than the one
 for #1455 was (I'll stop doing that, I promise).

 One of the reasons is that as said, processing the update section is quite
 nontrivial. I also did a few refactors that made me change some code from
 #1455 again (mainly easier to read unit tests, and member variables in the
 session instead of passing zname, zclass and datasrc_client around all the
 time)

 Some notes:
 - I added a few local helper functions, which may be very useful in a more
 general sense, both in session.py and the unit tests. But for now I've
 left them local (especially the rrset-looper, which contains some python
 voodoo, for which there may be better python voodoo)
 - It may be controversial, but I thought the code is much better with the
 previously mentioned member variables; instead of returning (zname,
 zclass, datasrc_client), __get_update_zone() now sets them in the session.
 It also sets one ZoneFinder, instead of calling find_zone over and over
 again.
 - The 'prescan' functionality as described in RFC2136 keeps track of
 whether it has seen a SOA record;   this should make filling in the
 'update serial' code much easier.
 - another potentially controversial thing is that at some point it checks
 for a range of RRType values, to filter out the meta-types. Since we
 haven't implemented all of these (yet?) doing so by name isn't possible,
 but maybe there's a better way that I can't think of right now :)

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