"dnstap" system test fixes
The fstrm_capture.out file is overwritten when the fstrm_capture utility is restarted during the "dnstap" system test. Use a separate output file for each fstrm_capture instance to ensure all output produced by that tool during the "dnstap" system test is preserved for forensic purposes.
The fstrm_capture utility is started in the background during the "dnstap" system test. Consequently, "rndc dnstap-reopen" and similar commands may be executed before fstrm_capture starts listening on the Unix domain socket it is configured to receive dnstap data on. This results in the dnstap data sent to that socket in the meantime to be lost; while the fstrm writer thread is able to recover from such a scenario within a couple of seconds (by reopening the configured dnstap destination itself), only one write attempt is made for data successfully queued to the writer thread, so dnstap frames can still be lost in the process. This may happen during the "dnstap" system test, leading to the dnstap output file being empty, which in turn causes the test to fail.
Fix by waiting until fstrm_capture starts listening on the Unix domain socket it is configured to use before asking named to reopen the configured dnstap destination. Since various fstrm_capture versions log different messages when the listening socket is set up, wait for a common string that works for all fstrm_capture versions released to date. Add a few extra debug messages indicating test progress and make the test fail if the expected fstrm_capture log message is not generated within 10 seconds.
Lower the size requirement for the dnstap output file produced during the "dnstap" system test from 454 to 450 bytes; while files of that size are not generated in any GitLab CI job, they are in other environments where the test passes.
Closes #4240 (closed)