[python] chore: fix python 3.11 bug with async wait_for

[fresh-borzoni]

The tests wrapped async iterator consumption in asyncio.wait_for() as a safety net against hangs. But on Python prior to 3.12 fix(python/cpython#96764), wait_for itself has a bug (cpython#96764). Combined with future_into_py/Python::attach(), this creates a GIL deadlock. The safety net was causing the very hang it was meant to prevent.

pytest-timeout (30s per test) is the safety net now. It works at the process level, not the asyncio level, so it can't deadlock. If the async iterator hangs, it's a real bug that deserves a full stack trace from pytest-timeout.

related to https://github.com/apache/fluss-rust/actions/runs/24237394524/job/70768262474?pr=485

[fresh-borzoni]

@leekeiabstraction PTAL 🙏
cc @qzyu999

[qzyu999]

Hi @fresh-borzoni, great catch! I took a look and it appears that the entire functionality is preserved, while avoiding the downfall of the pre-3.12 deadlocking problem. Should this be noted somewhere in the documentation that users should avoid this Python function if they are running a Python version <3.12? We can add it in bindings/python/README.md or some other appropriate section:

Note on Asynchronous Iteration (Python < 3.12)
If you are consuming Fluss tables asynchronously in Python 3.11 or older, avoid wrapping the LogScanner async iterator directly in asyncio.wait_for(). Due to a known bug in CPython's task cancellation (Issue #96764), doing so can result in a GIL deadlock. If timeouts are necessary, it is highly recommended to upgrade to Python 3.12+, or handle timeouts at the process/test-runner level (e.g., using pytest-timeout).

[leekeiabstraction]

Approved. Thank your for fixing!

[fresh-borzoni]

@qzyu999 It's a good idea, thank you, but I prefer to wait a bit to verify that the fix is reliable and we don't have any further issues.
This fix provides us a proper termination with stack-trace, so it will easier to reason If something is still off after this fix.