We tend to have jobs that raise exceptions on occasion due to issues like network timeouts, etc. that we expect to happen regularly. Given a list of retryable_exceptions, we might want jobs that raise one of these exceptions to not send an error notification until their last retry is exhausted. This way we can eliminate extra noise from errors that we expect to happen, but still allow these jobs to retry (and eventually succeed), while still receiving immediate notifications for unexpected errors.

This could be implemented in the Sidekiq integration to not send an error report if the exception is in the list of retryable_exceptions and the job has remaining retries.

I'm happy to take a stab at a PR that integrates this, but curious if this seems like it is within the scope of an integration, or if the integrations are intended to be very simple, and if there's a precedence for adding configuration options like retryable_exceptions that's specific to a particular integration.