This commit attempts to include guidance to developers implementing web hook sending behavior. Specifically it provides what I believe to be common-sense retry intervals that should be appropriate for most cases.

The values defined were determined after reviewing the webhook documentation of a number of public APIs. I saw total retry periods ranging from as little as 5 minutes from Pusher, to more than 12 days from Marqueta. Some APIs used constant intervals, others used linearly increasing, others exponential. In order to account for minor network glitches and still provide a reasonably large total retry period, I believe that using an exponential approach is the most appropriate.

The initial retry period of 1 minute was chosen because it was twice the timeout period and it allows the interval to be easily calculated as 2^(# of retries) minutes. This means only the retry count needs to be maintained between requests. Retry count is needed anyway to stop at the max of 10.

I stopped at 10 because it was a nice round number :-) and it provided a total elapsed of 17 hours. If a service is down for more than 17 hours, not receiving a notification is probably the least of its concerns.

I added the clause about respecting the retry-after header because if a server is going through some upgrade process that it knows will take 10 minutes and makes the effort to tell people in the retry-after header, it seems pointless to call it at 1, 2 and 4 minutes.