HTTP client should have some retry mechanism

[halkyon]

In some cases, HTTP responses from Let's Encrypt have returned a 50x during Let's Encrypt downtime, or a rate limit was hit. This client should probably handle these gracefully. I would also suggest using Guzzle instead of curl, which allows greater flexibility in handling HTTP requests from PHP, such as adding a retry middleware.

From the Let's Encrypt docs here: https://letsencrypt.org/docs/integration-guide/

Renewal failure should not be treated as a fatal error. You should implement graceful retry logic in your issuing services using an exponential backoff pattern, maxing out at once per day per certificate. For instance, a reasonable backoff schedule would be: 1st retry after one minute, 2nd retry after ten minutes, third retry after 100 minutes, 4th and subsequent retries after one day. You should of course have a way for administrators to request early retries on a per-domain or global basis. Backoffs on retry means that your issuance software should keep track of failures as well as successes, and check if there was a recent failure before attempting a fresh issuance. There’s no point in attempting issuance hundreds of times per hour, since repeated failures are likely to be persistent.

[stonemax]

I has considered your suggestion, but there are some difficulties. 50x error may be caused by LE server self, or may be caused by params error of client requests. I have to find a way to find the difference between them.

Not to use guzzle because I this it's too heavy for this simple project, but guzzle is still an excellent package.