gh-159583: Fix IndexError in imaplib IDLE iteration on a tagged response

[MrGreyfun]

Continue reading in Idler._pop() until an IDLE response is queued or the original timeout expires.

An earlier pipelined command's tagged response can arrive during IDLE. _get_response() records it in tagged_commands without queuing an IDLE response, so _pop() previously raised IndexError when it popped the empty queue. It now measures each read against the original deadline, so receiving a tagged response does not extend duration or burst() timeouts.

Tests: PCbuild/amd64/python_d.exe -m test test.test_imaplib (267 tests run, 3 skipped).

Fixes #159583.

• Issue: imaplib.Idler raises IndexError when another command's tagged response arrives during IDLE #159583

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[foresto]

As I explained in #159583, this patch is trying to fix something that I believe is not a bug in imaplib, but a bug in the author's internal IMAP server implementation. One of us has misunderstood how IMAP command continuation request responses work. :)

We might consider adding a check to gracefully detect and report the broken server behavior, rather than raising IndexError, but the check would impose a small performance cost in IDLE loops. If we decide that's an appropriate tradeoff, I think it should be proposed in a separate PR.

-1 from me on this PR.

[MrGreyfun]

Thanks for the detailed explanation. I see your point about the continuation request still being pending in RFC 3501 section 2.2.1, and I agree that my interpretation of this part of the protocol may have been too broad.

I will not pursue the protocol interpretation further. Please use your judgment on whether the current behavior should be treated as an invalid server response and whether a separate change should report it as a controlled error.

I'll leave this PR to your assessment.