timing race in setnsec3param task

In zone_postload() the queued zone->setnsec3param_queue get scheduled as regular tasks:

    /*
     * Process any queued NSEC3PARAM change requests. Only for dynamic
     * zones, an inline-signing zone will perform this action when
     * receiving the secure db (receive_secure_db).
     */

However, the original reason why the NSEC3PARAM change requests were originally queued depends on following code:

    /*
     * setnsec3param() will silently return early if the zone does not yet
     * have a database.  Prevent that by queueing the event up if zone->db
     * is NULL.  All events queued here are subsequently processed by
     * receive_secure_db() if it ever gets called or simply freed by
     * zone_free() otherwise.
     */

So, when all the queued events gets scheduled as tasks in the zone_postload() and the tasks are fired up, the zone->db still might be NULL. Due to a difference in scheduling this doesn't really happen with the old (separate) task manager, but it's very easy to trigger in the taskmgr@netmgr.