IMAP: Fix handling of the CLOSED response code
The [CLOSED] response code is used to indicate the precise moment where all
subsequent responses relate to the *new* mailbox instead of the old one. Without
it, there is a time window when switching mailboxes where the client cannot be
sure on what mailbox the server is talking about. Consider this sequence of
events:
- a mailbox is open with 3 messages
- a client decides to open another mailbox which previously contained just 2
messages:
>>> x01 SELECT new-mailbox
- the last message in the old mailbox is updated by another client, and its
flags change:
<<< * 3 FETCH (FLAGS (\Seen))
As we have already sent out our SELECT, and we are expecting responses which are
going to describe the new mailbox (such as EXISTS, RECENT, UIDVALIDITY and what
not). The problem is that the server might want to send us other data related to
the older mailbox -- perhaps because they were already on the wire by the time
we sent our SELECT (and there's always room for these race conditions).
This patch changes the behavior to make sure that all responses are delivered to
the old KeepMailboxOpenTask until a CLOSED is seen, but only in case where the
server is known to support QRESYNC. Unfortunately, there isn't much that we
could do for the case of a server which doesn't do QRESYNC, and Trojita might
still occasionally report an error when you happen to switch mailboxes at the
exact same time something interesting happens. This could be probably further
improved by ignoring FETCH responses until an EXISTS arrives (or something like
that), but I'm not convinced that this is worth the effort and complexity, as
the support for QRESYNC is rather common nowadays (fortunately).
BUG: 324761
Change-Id: Ief931474c2d1b5e053f027146f5d4a339fbfe0b3