Add exponential backoff retries for HTTP requests

[EverlastingBugstopper]

Description

• What does it do?
  • On any HTTP request that we think might resolve on a retry (maybe we should default to 500 type errors and perhaps specific RoverClientErrors) we should have Rover retry the request. We need to be careful not to just retry everything though, we need to be explicit about the exact scenarios in which retries are desired.
• What are the inputs/outputs?
  • I'm thinking we either implement retries by default, with a way to opt-out. Maybe there's a --no-retry flag that we add for this one on any command that uses a Client. We only use one Client in Rover due to recent refactors which should make this change very straightforward!
• Prior art
  • I wanted a band-aid for our own CI
  • We closed that PR in order to pursue implementing this in a more general way using something like this snippet demonstrating usage of the exponential backoff crate.
• What is your use case for this?
  • Sometimes HTTP requests fail! Most of the time those 500-type errors will resolve themselves if you just do a retry. Would make Rover more resilient to blips with Apollo Studio and blips on user's GraphQL servers themselves.

[EverlastingBugstopper]

I'm having a hard time integrating the backoff error API with our own, so I'm going to try using the retry crate instead.

[EverlastingBugstopper]

no dice on retry... might have to just do some looping manually. the problem i'm running into is the error types returned by these libraries don't give me an easy way to return a Result<T, RoverClientError> and I can't seem to map things properly.

[EverlastingBugstopper]

I think my main issue here was trying to integrate this into the existing codebase. I've split out some of what I want into this example repo that should help me integrate the logic into Rover directly. I also played around with httpmock which seems very promising for expanding some of our test coverage.