connect: expire the timeout when trying next

[bagder]

... so that it gets called again immediately and can continue trying addresses to connect to. Otherwise it might unnecessarily wait for a while there.

Fixes #11920
Reported-by: Loïc Yhuel

[icing]

Does not hurt, since Curl_expire() is idempotent when called several times.

[hwti]

This doesn't always work in my tests.

Curl_expire returns in the "sooner" ( if(diff > 0) ) case, with nowp pointing to the current timeout (which triggered the curl_multi_perform and will be removed at the end). I wonder if this is expected.
And after this, multi_timeout can either :

• find the newly added timer and returns 0
• find the next timer (the connection timeout in my case)

[bagder]

Yes, on repeated runs it shows for me as well. A premature PR...

[bagder]

@hwti okay, how about this? I actually poked on Curl_expire now as I believe the "optimization" in there could get it wrong.

[hwti]

@bagder The commit seems to avoid the issue, but the current timeout remains in the list until the next curl_easy_perform, since add_next_timeout is no longer called on the current call.

I have another solution in add_next_timeout : #11937.
It might fix more cases : if there are two similar timeouts, when the first one is serviced the second one might expire in less than 1ms, and would currently be removed from the list.
With this one, I believe the Curl_expire optimization can be kept.

[hwti]

I created #11938 and #11939 to reduce the number of useless wakeups.
The two successive curl_multi_perform were sometimes hiding the issues, so this could help detecting them, but also break cases which appeared to work most of the time.

[bagder]

I believe the Curl_expire optimization can be kept.

I believe so as well. I removed the commit again from this PR.