Do not delete nodes from non-existent zone's NSEC3 hash trees

[wtoorop]

This fixes a bug where the reload process crashes because a node in a zone's NSEC3 hash tree is tried to be deleted, but the tree is not or no longer there. I.e. zone->hashtree == NULL.

I still don not know what the root cause of the zone->hashtree being NULL is, but the consequence of the crash is quite severe. Not only will the zone in question not be updated, but since the xfr that caused it is not marked faulty, the reload will just happen again and again with all the outstanding xfrs, causing the crash to just happen over and over again, and none of the other outstanding xfrs being applied (stalling those zones).

We may consider conveying the xfr number being processed by the reload process to the old-main process, so that the old-main can mark it as faulty if a crash happens during processing of that xfr, so that the other xfrs can still be processed (and will not be blocked). @wcawijngaards @mozzieongit WDYT?

[mozzieongit]

This seems like a decent immediate solution. And finding the root cause later should be fine.

We may consider conveying the xfr number being processed by the reload process to the old-main process, so that the old-main can mark it as faulty if a crash happens during processing of that xfr, so that the other xfrs can still be processed (and will not be blocked).

That sounds like a good idea.

[wcawijngaards]

This code change is fine. It is also good to have as a defense in depth, after other fixes are found for the root cause possibly, then this code is still useful to have.