Handle exceeding Github rate limits

Nell’issue non sono indicati file o test. Inizia individuando i punti di ingresso delle richieste REST e GraphQL del client e la gestione degli errori esistente. Definisci come i tentativi configurabili debbano usare gli header del rate limit e le indicazioni di backoff, quindi aggiungi una copertura che dimostri che le richieste soggette a rate limit attendono o falliscono in base alla configurazione.

From:
https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#exceeding-the-rate-limit

If you exceed your primary rate limit, you will receive a 403 or 429 response, and the x-ratelimit-remaining header will be 0. You should not retry your request until after the time specified by the x-ratelimit-reset header.

If you exceed a secondary rate limit, you will receive a 403 or 429 response and an error message that indicates that you exceeded a secondary rate limit. If the retry-after response header is present, you should not retry your request until after that many seconds has elapsed. If the x-ratelimit-remaining header is 0, you should not retry your request until after the time, in UTC epoch seconds, specified by the x-ratelimit-reset header. Otherwise, wait for at least one minute before retrying. If your request continues to fail due to a secondary rate limit, wait for an exponentially increasing amount of time between retries, and throw an error after a specific number of retries.

Continuing to make requests while you are rate limited may result in the banning of your integration.

It would be nice if simple-github automatically handled this for consumers, though the behaviour should be configurable as there may be cases where consumers would rather schedule other work instead of waiting for the rate limit to grow again.