rest_client: Improve async() handling in "delayed 200 OK" scenarios

In case the 200 OK reply or its body take several seconds to arrive, do
not break the loop prematurely due to a 500ms hardcoded loop timeout and
re-use the configurable "curl_timeout" modparam as loop timeout instead.

(cherry picked from commit 532d8e8)

modules/rest_client/rest_client.c

@@ -57,8 +57,8 @@ unsigned int max_transfer_size = 10240; /* KB (10MB) */
  * curl_multi_perform() may indicate a "try again" response even
  * when resuming transfers with pending data
  */
-int _async_resume_retr_timeout = 500000; /* us */
-int _async_resume_retr_itv = 100; /* us */
+int _async_resume_retr_timeout; /* us; equal to @curl_timeout */
+int _async_resume_retr_itv = 500; /* us */
 
 /* libcurl enables these by default */
 int ssl_verifypeer = 1;
@@ -239,6 +239,7 @@ static int mod_init(void)
 	LM_DBG("Initializing...\n");
 
 	connection_timeout_ms = connection_timeout * 1000L;
+	_async_resume_retr_timeout = curl_timeout * 1000000U;
 
 	if (connect_poll_interval < 0) {
 		LM_ERR("Bad connect_poll_interval (%ldms), setting to 20ms\n",

modules/rest_client/rest_methods.c

@@ -882,7 +882,8 @@ static enum async_ret_code _resume_async_http_req(int fd, struct sip_msg *msg,
 		 * server body download will be performed within this loop, blocking */
 
 		mrc = curl_multi_perform(multi_handle, &running);
-		LM_DBG("perform result: %d, running: %d\n", mrc, running);
+		LM_DBG("perform result: %d, running: %d (break: %d)\n", mrc, running,
+			mrc != CURLM_CALL_MULTI_PERFORM && (mrc != CURLM_OK || !running));
 
 		if (mrc != CURLM_CALL_MULTI_PERFORM &&
 		     (mrc != CURLM_OK || !running))