fix(aci): Retry failed Seer anomaly data fetches

[kcons]

Rather than failing on the first try, attempting to retry up to twice will make minor Seer availability blips non-events.
Worst-case added backoff should be 1.5s, which I think is tolerable in all contexts and generally preferable to failure.

[sentry]

Bug: The urllib3.Retry object is not configured to retry on TimeoutError exceptions, causing immediate failure instead of retries.
_{Severity: MEDIUM | Confidence: High}

🔍 Detailed Analysis

The urllib3.Retry object, initialized with Retry(total=2, backoff_factor=0.5), does not automatically retry on TimeoutError exceptions. By default, it only retries on connection-related errors and specific HTTP status codes. Consequently, if a TimeoutError occurs during a Seer API call, the request will fail immediately without retrying, which contradicts the pull request's stated intention to handle minor availability blips.

💡 Suggested Fix

Configure the urllib3.Retry object to explicitly retry on TimeoutError by either adding TimeoutError to raise_on_status or raise_on_connection_error (if applicable) or by implementing a custom retry strategy.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/sentry/seer/anomaly_detection/get_anomaly_data.py#L35

Potential issue: The `urllib3.Retry` object, initialized with `Retry(total=2,
backoff_factor=0.5)`, does not automatically retry on `TimeoutError` exceptions. By
default, it only retries on connection-related errors and specific HTTP status codes.
Consequently, if a `TimeoutError` occurs during a Seer API call, the request will fail
immediately without retrying, which contradicts the pull request's stated intention to
handle minor availability blips.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference_id: 2866257}