As discussed in https://bugzilla.gnome.org/show_bug.cgi?id=667725#c5 it is a design flaw for imapx_untagged() to care about the requests have been made to the server, and make decisions based on them.

The IMAP protocol is the way it is, and the information about the messages/mailboxes is *untagged*, for a reason.

We should just "eat" the state that we're told about, whether it be solicited or unsolicited, and amend our local data store to reflect the information we gained.

There is a need for *some* co-ordination, particularly in scan_changes (for non-QRESYNC) when we need to notice that a given message is now absent purely because we *don't* see it in the FETCH 1:* (UID FLAGS) responses.

But that's still not something that has to be handled in imapx_untagged(). It's enough just to put a 'last seen' marker on each message as we see it, then scan_changes can know that after its fetch is completed, any message which doesn't have an updated 'last seen' marker has gone from the mailbox and should be removed locally. All the logic can still be on the 'job' side, and imapx_untagged() knows nothing about the jobs.

Get this right, and we shouldn't need a thread for idle either.