[Bug/Suggestion] Better Rate Limit Handling

[devonzara]

Situation During the early stages of development, before getting around to implementing caching & API throttling, I inadvertently triggered a re-render loop on the frontend. This caused an excessive number of requests to the backend, which in turn spammed the Spotify API.

Consequently, my app was suspended for approximately 24 hours and I began receiving the following responses:

GET /v1/artists/5zixe6AbgXPqt4c1uSl94L HTTP/1.1
Content-Type: application/json
Authorization: Bearer ████████████████████████████████████████████████████████████████████████████████████████████████████████████
User-Agent: PostmanRuntime/7.37.3
Accept: */*
Postman-Token: ███████████████████████████████████
Host: api.spotify.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
 
HTTP/1.1 429 Too Many Requests
cache-control: private, max-age=0
retry-after: 74523
access-control-allow-origin: *
access-control-allow-headers: Accept, App-Platform, Authorization, Content-Type, Origin, Retry-After, Spotify-App-Version, X-Cloud-Trace-Context, client-token, content-access-token
access-control-allow-methods: GET, POST, OPTIONS, PUT, DELETE, PATCH
access-control-allow-credentials: true
access-control-max-age: 604800
content-encoding: gzip
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
date: Sun, 30 Jun 2024 02:39:13 GMT
server: envoy
Via: HTTP/2 edgeproxy, 1.1 google
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Transfer-Encoding: chunked
 
Too many requests

Notice that the retry-after header is 74623 and the response body is not in JSON format as expected. This causes zmb3/spotify to throw a "spotify: couldn't decode error: (17) [Too many requests]" error.

Suggestions

1. Handle the plain text response body as an edge case.
2. Implement a maxWait (also suggested in #241) or similar mechanism for retries.
3. Provide access to the raw response or retry-after header value so the application can decide how to handle the situation.