It seems, curl_multi_socket_action() can fail with

  connectivity check failed: 4

where "4" means CURLM_INTERNAL_ERROR.

When that happens, it also seems that the file descriptor may still have data
to read, so the glib IO callback _con_curl_socketevent_cb() will be called in
an endless loop. Thereby, keeping the CPU busy with doing nothing (useful).

Workaround by disabling polling on the file descriptor when something
goes wrong.

Note that optimally we would cancel the affected connectivity-check
right away. However, due to the design of libcurl's API, from within
_con_curl_socketevent_cb() we don't know which connectivity-checks
are affected by a failure on this file descriptor. So, all we can do
is avoid polling on the (possibly) broken file descriptor. Note that
we anyway always schedule a timeout of last resort for each check. Even
if something goes very wrong, we will fail the check within 15 seconds.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996