Feature request: customize retry strategy

[gribnoysup]

Hey-o! Thanks for the amazing library 🎉👏

I was wondering if you would be open to an idea of making it possible to configure the retry strategy through some kind of API exposed by the library.

In my specific use case, I would like to enable retries for 404 response codes (exactly for the reasons described in #19) and POST requests (yeah, I know, but some third-party APIs in the wild are allowing POST instead of GET when the payload for the request is too big to fit in query, for example).

Regarding the #19, I understand the decision behind disabling the retries and leaving it to the user to re-implement, but I would ask to maybe re-evaluate it as the issue with this approach, in my opinion, is that it means that the user will need to re-implement all the things like caching and all the other parts of the retry mechanism.

Anyway, this is just a question/suggestion, feel free to close it if it doesn't match the direction of this library 🙏

[xzyfer]

When using GraphQL for inter-service communication it's common for those requests to be POST by default, often without the option of using GET as a viable alternative (due to query string length restrictions.)