Fix nested retry loops for transient network errors

[shayonj]

Summary

Fixes a regression where transient network errors (like DNS failures) cause nested retry loops,
resulting in ~16 retry attempts instead of 4 and significantly longer failure times (~17-19s vs ~4s).

Problem

After #17104, both the middleware (RetryTransientMiddleware) and the cached client layer
(RetryState::should_retry) independently retry transient network errors. When the middleware
exhausts its retry budget and returns an error, should_retry starts a fresh retry loop,
causing nested retries.

Fix

RetryState::should_retry now only tracks middleware retries for error reporting instead of
initiating additional retries for transient errors. The middleware already handles transient
retry logic, so duplicating it here causes the nested loops.

Test Plan

• All existing network tests pass
• Manual test with invalid DNS shows ~4s failure time (was ~17-19s) using the replication script in 0.9.20: DNS failures take ~4x longer due to nested retries #17266

[zanieb]

It's fine to break API compatibility here, every release is considered breaking at this time.

[shayonj]

looks like there is a fix proposed in #17274. Closing on behalf

[EliteTK]

@shayonj ah, my apologies, I had missed that you were already working on a fix.

[shayonj]

no probs at all! thank you for the fast fix