Make dnstap work reliably with netmgr

The introduction of netmgr doubled the number of threads from which
dnstap data may be logged: previously, it could only happen from within
taskmgr worker threads; with netmgr, it can happen both from taskmgr
worker threads and from network threads.  Since the argument passed to
fstrm_iothr_options_set_num_input_queues() was not updated to reflect
this change, some calls to fstrm_iothr_get_input_queue() can now return
NULL, effectively preventing some dnstap data from being logged.
Whether this bug is triggered or not depends on thread scheduling order
and packet distribution between network threads, but will almost
certainly be triggered on any recursive resolver sooner or later.  Fix
by requesting the correct number of dnstap input queues to be allocated.

bin/named/server.c

@@ -3677,7 +3677,11 @@ configure_dnstap(const cfg_obj_t **maps, dns_view_t *view) {
 		}
 
 		fopt = fstrm_iothr_options_init();
-		fstrm_iothr_options_set_num_input_queues(fopt, named_g_cpus);
+		/*
+		 * Both network threads and worker threads may log dnstap data.
+		 */
+		fstrm_iothr_options_set_num_input_queues(fopt,
+							 2 * named_g_cpus);
 		fstrm_iothr_options_set_queue_model(
 			fopt, FSTRM_IOTHR_QUEUE_MODEL_MPSC);
 

bin/tests/system/dnstap/ns3/named.args

@@ -0,0 +1,2 @@
+# Using "-n 1" allows GL #1795 to be reliably reproduced
+-D dnstap-ns3 -X named.lock -m record,size,mctx -c named.conf -d 99 -g -U 4 -n 1

util/copyrights

@@ -413,6 +413,7 @@
 ./bin/tests/system/dnstap/README		TXT.BRIEF	2019,2020
 ./bin/tests/system/dnstap/clean.sh		SH	2015,2016,2017,2018,2019,2020
 ./bin/tests/system/dnstap/large-answer.fstrm	X	2019,2020
+./bin/tests/system/dnstap/ns3/named.args	X	2020
 ./bin/tests/system/dnstap/setup.sh		SH	2018,2019,2020
 ./bin/tests/system/dnstap/tests.sh		SH	2015,2016,2017,2018,2019,2020
 ./bin/tests/system/dnstap/ydump.py		PYTHON	2016,2017,2018,2019,2020