dnsdist: Fix several bugs in the TCP code path, add unit tests

[rgacogne]

Short description

This PR fixes several issues in corner cases, introduced during the refactoring for out-of-order support. It also adds a lot of unit tests for that TCP code, which was planned for 1.7.0 but fast-forwarded because of issues reported with 1.6.0-alpha1.

It also adds a new configuration option, setTCPInternalPipeBufferSize, that can be used to set the size of the buffer of the internal pipe used to pass queries to TCP worker threads, thus allowing a smoother handling of incoming TCP connections peaks.

The diff seems huge but most of that (3200 out of 3900 additions) comes from the new unit tests, which actually amount to more lines of code than the TCP code itself and provides a very nice code coverage (which unfortunately does not prevent bugs from still hiding in a unexpected state.. ;-)).

One caveat is that this drops source selection support other than via SO_BINDTODEVICE, because having to pass the source interface name and index down to the actual sendmsg code is very annoying. Perhaps we should at least look into supporting IP_SENDIF in addition to SO_BINDTODEVICE?

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[omoerbeek]

Nice to see more general TCP FastOpen support. I'm a bit worried about the source binding changes as you are relying on specific functions. Both alternatives are not generally available.

[omoerbeek]

Nice to see more general TCP FastOpen support. I'm a bit worried about the source binding changes as you are relying on specific functions. Both alternatives are not generally available.

Thinking about this a bit more, the old-fashioned way of binding to a source address before connect should still work, right?

[rgacogne]

Thinking about this a bit more, the old-fashioned way of binding to a source address before connect should still work, right?

Yes, that only concerns source interface selection, sorry!

[omoerbeek]

Something to investigate: I did not have TCP_FASTOPEN_CONNECT, but it seems I did not get the fallback to MSG_FASTOPEN either.

The fallback to MSG_FASTOPEN if the include is not there is enabled, but does not seem tot work as intended for sdig using the write call.

[rgacogne]

Something to investigate: I did not have TCP_FASTOPEN_CONNECT, but it seems I did not get the fallback to MSG_FASTOPEN either.

The fallback to MSG_FASTOPEN if the include is not there is enabled, but does not seem tot work as intended for sdig using the write call.

Fixed the detection of TCP_FASTOPEN_CONNECT and the handling of MSG_FASTOPEN in blocking mode (only the non-blocking one was supported). I also added a fastOpen option to sdig.

[omoerbeek]

Nice, when this is merged, I'll make a PR to change the two write calls in sdig into as single one.

[omoerbeek]

FastOpen works now as expected in sdig. I do see two writes in captures, but that is expected. I browsed the rest of the changes, and found nothing surprising.

[rgacogne]

Rebased to fix some commits not compiling.