Repeatedly we see problems where using curl_multi_wait() is difficult or
just awkward because if it has no file descriptor to wait for
internally, it returns immediately and leaves it to the caller to wait
for a small amount of time in order to avoid occasional busy-looping.

This is often missed or misunderstood, leading to underperforming
applications.

This change introduces curl_multi_poll() as a replacement drop-in
function that accepts the exact same set of arguments. This function
works identically to curl_multi_wait() - EXCEPT - for the case when
there's nothing to wait for internally, as then this function will by
itself wait for a "suitable" short time before it returns. This
effectiely avoids all risks of busy-looping and should also make it less
likely that apps "over-wait".

This also changes the curl tool to use this funtion internally when
doing parallel transfers and changes curl_easy_perform() to use it
internally.

Turned bad with commit b8894085000

Reported-by: niallor on github
Fixes #4172
Closes #4173

It was used (intended) to pass in the size of the 'socks' array that is
also passed to these functions, but was rarely actually checked/used and
the array is defined to a fixed size of MAX_SOCKSPEREASYHANDLE entries
that should be used instead.

Closes #4169

Regression, broken in commit 65eb65fde64bd5f (curl 7.64.1)

Reported-by: Jonathan Cardoso Machado
Assisted-by: Jay Satiro

Fixes #4136
Closes #4162

Follow-up to eb9a604f. Mistake caused by me when I edited the commit
before push...

Closes #4157

... to avoid integer overflows later when multiplying with 1000 to
convert seconds to milliseconds.

Added test 1269 to verify.

Reported-by: Jason Lee
Closes #4166

... to make CURLOPT_MAX_RECV_SPEED_LARGE and
CURLOPT_MAX_SEND_SPEED_LARGE work correctly on subsequent transfers that
reuse the same handle.

Fixed-by: Ironbars13 on github
Fixes #4084
Closes #4161