With support for concurrent challenges (i.e. running multiple calls to Certificate.Obtain() or Certificate.Renew() at the same time -- different certs of course) I think it would be a good idea to make sure that lego doesn't hammer any the CA.

For example, if a client (user of lego) needs to obtain 100 certificates, it should be able to call Obtain() 100 times at once, but lego should be sure to space out the individual ACME API requests by some time.

So, a configurable rate limit such as MinAPIRequestInterval would be useful.

The only alternative right now is for the user/importer of lego to do their own throttling. But this is not very effective... The difference between what I am proposing and just leaving it up to the user of lego do their own rate limiting is that rate limiting implemented into lego would apply directly to individual ACME API calls, which lego hides away from the user. The only thing the user can throttle themselves is the number of issuances at once, which is less useful because issuances are comprised of more than just a single API call. In other words, Certificate.Obtain() does not correspond to fixed amount of load on CA. This detail is hidden from the user, and so the rate limit needs to be applied within lego.

For example: setting MinAPIRequestInterval to 2 * time.Second would allow a user to call Obtain() 100 times all at once, but lego would make sure that only 1 request goes to each endpoint once every 2 seconds. (I think it is better for the rate limit to apply per endpoint instead of all endpoints in the same bucket.)

This would speed up certificate issuances while respecting the CA's infrastructure.

What do you think?