getaddrinfo can hang for many seconds when the system stub resolver
misbehaves; running it inline on the event loop froze every other
request, IPC, and curl socket event for the duration.
New PendingSystemResolution coalesces concurrent lookups for the same
name, dispatches the call to a Threading::ThreadPool worker, and
deferred-invokes the result back to the originating event loop. Each
caller of lookup() gets its own Core::Promise so concurrent
when_resolved/when_rejected handlers can't clobber each other; the
pending state fans out to every joined caller on completion.
Workers issue A and AAAA in parallel on separate sockets to sidestep
the systemd-resolved AAAA-drop bug, and resolve the user's promise
after the first side returns records (with a 50 ms RFC 8305 grace
window for the other side).
Adds Core::Socket::AddressFamily and an optional parameter to
resolve_host so workers can request A or AAAA specifically.
The system uses ssize_t so it can return -1 in case of an error. But in
our case, we will transform that to an AK::Error, thus we never return
-1. Let's return size_t instead.
Previously, we only returned the first result that looked like an IPv6
or IPv4 address.
This cropped up when attempting to connect to https://cxbyte.me/ whilst
IPv6 on the server wasn't working. Since we only returned the first
result, which happened to be the IPv6 address, we wasn't able to
connect.
Returning all results allows curl to attempt to connect to a different
IP if one of them isn't working, and potentially make a successful
connection.
The "ready to write" notifier we set up in generic socket connection is
really only meant to detect a successful connection. Once we have a TCP
connection, for example, it will fire on every event loop iteration.
This was causing IRC Client to max out the CPU by getting this no-op
notifier callback over and over.
Since this was only used by TLSv12, I changed that code to create its
own notifier instead. It might be possible to improve TLS performance
by only processing writes when actually needed, but I didn't look very
closely at that for this patch. :^)
