daemon: decrease tcp backlog to 128

From our TCP benchmarks, values over 128 don't seem to have any
measurable benefits, even with hundreds of thousands of connections.

On the contrary, during very high TCP and CPU load, smaller backlog
seems to dramatically improve latency for clients that keep idle TCP
connections.

During normal/low load, smaller backlog doesn't seem to have any
benefits.

When measured against "aggressive" clients that immediately close the
TCP connection once their query is answered, backlog smaller than 128
was measured to hurt performance.

The application's backlog size is ultimately limited by
net.core.somaxconn, which has been set to 128 prior to Linux 5.4.
Therefore, this change only affects newer kernels and those who have
manually set this value to a higher size.

For more, see
https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/968

NEWS

@@ -5,6 +5,7 @@ Improvements
 ------------
 - cache garbage collector: reduce filesystem operations when idle (!946)
 - policy.DEBUG_ALWAYS and policy.DEBUG_IF for limited verbose logging (!957)
+- daemon: improve TCP query latency under heavy TCP load (!968)
 
 Bugfixes
 --------

daemon/engine.c

@@ -43,9 +43,11 @@
 #endif
 
 /**@internal Maximum number of incomplete TCP connections in queue.
-* Default is from Redis and Apache. */
+* Default is from empirical testing - in our case, more isn't necessarily better.
+* See https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/968
+* */
 #ifndef TCP_BACKLOG_DEFAULT
-#define TCP_BACKLOG_DEFAULT 511
+#define TCP_BACKLOG_DEFAULT 128
 #endif
 
 /* Cleanup engine state every 5 minutes */