Restructure code that makes zone modifications.

[johanix]

Right now we have code in lots of places that adds (or sometimes removes) RRs from a zone. In many there is also signing of a modified RRset. Finally there is locking when actually applying the changes to the zone data.

If we changed the code to only create (or modify) the RRset and then send it over to the UpdateEngine for possible signing and inclusion in the zone we would save a lot of code in a number of places. Another advantage would be that in the case where the zone cannot be modified and we need to store the changes (as a "todo-list") for an operator to apply manually, then that is also only done in one place instead of all over.

The only real drawback is the the UpdaterEngine at present deals with updates to zone data mostly structured as DNS UPDATEs stored inside an UpdateRequest blob. Either we add another format to what UpdaterEngine understands or we just construct the UpdateRequest blob when needed. The latter is probably best.

• Restructure publish/unpublish KEY in child zones
• Restructure publish/unpublish DSYNC in parent zones
• Restructure publication of DNSKEY in signed zones
• Restructure publication of CSYNC in child zones

Note: TDNS doesn't support CDS yet (as it cannot roll DNSKEYs yet).

[johanix]

There is some strangeness with the publication of address records for DSYNC receivers. The UpdateRequest looks absolutely correct, but when ApplyZoneUpdateToZoneData() processes the address records it complains about all of them being duplicates. But apparently it still publishes them, but it doesn't sign them for some reason.

[johanix]

Strangeness resolved. It was the old code that still published the address records before sending the UpdateRequest to UpdaterEngine. So they were already published, and hence the complaint about duplicates was correct.