[musl] TCP DNS outline

[Rich Felker <dalias@libc.org>]

What follow are some notes I've put together in preparation for TCP
fallback addition to DNS query core. Open to comments/concerns.



Current DNS query core state machine outline:

Single socket fd for sending/receiving UDP messages.
One or more answer buffers: answers[nqueries]
Lengths of accepted answers, 0 if none: alens[nqueries]

On each loop iteration, queries that don't yet have answers get
[re]sent if retry interval is exceeded.

UDP socket fd is poll()ed with timeout, then messages are recvfrom'd
and processed until no more are available. For each:

- It is read into the lowest-indexed answer buffer that's not yet
  filled.

- Query id is used to determine which question it goes with. If none
  or if that question already has an answer, it's discarded and
  processing continues to next packet.

- RCODE is checked; if non-conclusive the packet is ignored and
  processing continues to next packet (possibly with early retry, but
  this is not core to the logic)

- If answer it accepted, it's moved to the right answer slot (possibly
  the one it's already in) and the size is recorded, marking the slot
  as having an accepted answer.

This process continues until all questions have answers or timeout.



Changes for TCP:

Additional state:
For polling multiple socket fds: struct pollfd [nqueries+1]. This
requires nqueries be well-bounded, but it's always 1 or 2 anyway. The
+1 is for the UDP socket. The pollfd array itself can store socket fds
so we don't need separate storage for them.
Buffer positions for handling partial read: pos[nqueries]

Logic changes:

An answer slot that's being queried by TCP is always considered in-use
for the purpose of receiving UDP. If all (both) queries have switched
to TCP, no UDP will be accepted. UDP received for a slot that's
already in "TCP mode" will be dropped just like if the slot already
have a UDP answe.

When checking the validity (see above: query id, RCODE) of a UDP
answer, if the TC bit is set, a predicate will be evaluated to decide
whether to accept the truncated answer. If so, there is no change. If
not, a new TCP socket will be opened to the nameserver address that
issued the TC'd answer, and added to the pollfd set. (This should
probably use TCP fastopen API if the kernel supports it, and only fall
back if not. I think this means that, if the MSG_FASTOPEN sendmsg
succeeds, we can go straight to polling for read, and only need to
connect and poll for write first if it doesn't.) Buffer position is
initialized to -2 (2 bytes prior to payload start) for the prepended
BE16 length field that's not part of the answer and that will be read
into a separate location via iovec.

When poll reports a TCP socket writable, send the corresponding query
payload (looping to send the whole thing; assume it won't block after
partial send of <280 bytes). Then switch the pollfd events to only
poll for read.

When poll reports a TCP socket ready for read, use buffer position and
readv or recvmsg to iovec-read into answer size and answer payload,
advancing buffer position accordingly. If we reach the answer length,
or hit the full answer buffer size without reaching it, close the
connection and deem the answer completed. If we get EOF or socket
error or see an inconclusive rcode, close the connection and deem the
query failed (alens[i]=0).