RetryIf might need more information and greater control over the execution flow.

[newacorn]

Another implementation of RetryIfErr

* Support for delayed retry logic
* Support for resetting the request timeout before retrying
* Users can decide whether to retry based on the request error and the number of retries.
Estimating the time required for a request to complete is relatively straightforward, but when retries are factored in, it becomes challenging to gauge this time accurately.

At the same time, comment out the logic for retrying non-idempotent requests：

	if !retry {
			break
			// Retry non-idempotent requests if the server closes
			// the connection before sending the response.
			//
			// This case is possible if the server closes the idle
			// keep-alive connection on timeout.
			//
			// Apache and nginx usually do this.
			//
			// This assertion cannot ensure that the server has not read our request.
			// Even if part of the request has been read, retrying for a non-idempotent
			// request is still unsafe. It is better to leave this decision to the user.
			//
			// if err != io.EOF {
			//	break
			// }
		}

This logic only covers one case where the error is not io.EOF; in fact, there are many other situations and edge cases. For non-idempotent requests, we should not make assumptions for the user.

[erikdubbelboer]

Thanks!