tests: Improve debugging for extra unexpected child tasks

I can as well just leave this in instead of removing it every time I hit a
failure in the subsequent QVERIFY.

Change-Id: Ia4a7c72d0193827e013bfe3d47a0bd7a99567058
don't hardcode framewidth ...

Change-Id: I4eddda1485de94832b35462bfc5fb6b98879c6db
REVIEW: 119802
IMAP: Add a proper state for waiting for a CLOSED response code

The CONN_STATE_SELECTING_WAIT_FOR_CLOSED describes a state where the
SELECT/EXAMINE command was already issued, but the IMAP state machine waits for
a CLOSED response code to know that the previously open mailbox was finally
closed, and any subsequent responses describe the new one.

v2: Don't call it "another mailbox" as this state will be used when opening a
mailbox for the first time as well.

Change-Id: I53f33c6667f14d154b5c4ba7a68cfffb8552f0ad
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
Fix build failure when extra debug output is configured

The recent addition of -DQT_NO_CAST_FROM_ASCII broke this very rarely used
feature.

Change-Id: I45ede632e7bbe01b1f79ff867d2c2be85e9fe3dd
Merge "don't hardcode framewidth ..."
IMAP: Fix response routing while waiting for [CLOSED]

Turns out that the bug was that the KeepMailboxOpenTask already reseted its
isRunning flag, and hence decided to stop listening for these responses anymore.

We have to distinguish between the "not yet started" and "already finished"
states, if only for the resyncMailbox() to do the sane thing.

The reason on why one cannot actually use these responses in any way is that
there's a pretty big risk of introducing race conditions to the mix. Some of the
updates (like new message arrivals) absolutely require a followup action on our
side, such as discovering the UIDs, but we cannot do that at this time anymore
as another mailbox is already being selected. We *could* handle other updates
like VANISHED and FLAGS just fine, I guess, but then there would be that
annoying race condition when EXISTS arrives at first, we don't do anything about
it, and subsequently a FETCH updates the new arrival -- that would cause us to
scream out rather loudly. Another possible problem is handling only FLAGS
updates, but ignoring the EXISTS, etc.

Now I hope *this* is a reasonable final state.

BUG: 324761
Change-Id: Iaf9f75e7bfe6630f32af9cd6cea383e96f657598
tests: make the QRESYNC dumb initial state reusable

The other bits cannot use helperQresyncAInitial() as there are subtle
differences in the IMAP conversation.

Change-Id: Ifa56e5d82d403ac4ca71e187625403237d7fbdca
IMAP: Fix interaction of UNSELECT and [CLOSED]

There was a regression introduced by Ief931474c2d1b5e053f027146f5d4a339fbfe0b3
where UNSELECT would accidentally leave the connection in such a state where it
would complain if the subsequent SELECT did not include a [CLOSED] response
code. That doesn't make sense, of course -- the mailbox gets unselected at that
point, and we're now in the CONN_STATE_AUTHENTICATED.

Change-Id: I7d45c9815237969b1e4a773edc83fb09f199420e
Merge changes I7d45c981,Ifa56e5d8,Iaf9f75e7

* changes:
  IMAP: Fix interaction of UNSELECT and [CLOSED]
  tests: make the QRESYNC dumb initial state reusable
  IMAP: Fix response routing while waiting for [CLOSED]