Cap worker-lock retry interval to fix int-str overflow crash (fixes #19315 #18221)

[George3d6]

Cap WaitingLock / WaitingMultiLock retry interval at 10 minutes.

Without a cap, max(5, next * 2) silently promotes self._retry_interval to an int on the second call (Python's max preserves the larger operand's type, and 5 is an int), and it doubles without bound. Once it crosses the existing 10-minute "getting excessive" warning threshold, the warning log line calls str() on the int and eventually trips Python 3.11+'s 4300-digit int_max_str_digits limit (PEP 644), raising ValueError from inside the warning itself. __aenter__'s broad except Exception: pass (intended to absorb TimeoutError from timeout_deferred) swallows the ValueError before the retry loop sleeps, so the loop re-raises as fast as Python can emit tracebacks until the process is restarted.

The cap is hoisted into a module-level _LOCK_RETRY_CAP_SECS so both classes share it, and the excessive-timeout warning is restructured to fire exactly once per waiter (on the iteration that first reaches the cap) instead of either spamming every iteration or being silently suppressed.

Fixes #19315 and #18221.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[MadLittleMods]

There is already a PR to address this kind of thing: #19394

🤔 I think we can continue with the other PR which is a bit more fleshed out and is currently stuck at the stage of the review being addressed.