tests: Support specifying the list of mailboex manually
tests: switch the DeleteMailbox tests over to LibMailboxSync fixture
tests: switch to the c*** API as well
Merge commit 'kde/deleting-mailboxes-unselect~1'
IMAP: fix deleting of currently selected mailboxes

All deletion attempts are now scheduled via the KeepMailboxOpenTask. If the
mailbox being deleted is currently selected, it will be destructively closed
(and a random subset of messages removed, see RFC 3501) by sending of the CLOSE
command. Afterwards, the actual deletion happens as usual.

There's a couple of corner cases, hence the number of test cases. Hope this is
enough.
Fix lifetime of KeepMailboxOpenTask

Turns out that there was no place where a dying KeepMailboxOpenTask would
disassociate itself as the Parser's maintaingTask (not to be confused with a
mailbox' maintaingTask). This is a prerequisite for the next commit; the test
added in it was enough to trigger a rather confusing backtrace.
Make it possible to switch to another mailbox after the old one was deleted
Merge branch 'deleting-mailboxes-unselect'

BUG: 331680
REVIEW: 116791
cleanup: don't shadow the parent class, remove useless redefines
tests: port to LibMailboxSync's native features
IMAP: do not request STATUS of mailboxes which are going to be replaced

The LIST processing will replace the cached mailboxes with completely new
instances, so it doesn't make sense to issue a STATUS for something which is
going to be replaced anyway.

When LIST-STATUS is present, this makes even more sense -- even if the TreeItem
nodes were not replaced, the STATUS response would still arrive, so there is
little point in requesting it explicitly. But that's just a remark for future;
the TreeItemMailbox nodes are for now being replaced when a LIST response
arrives.
Return previously known values when asked for message counts

When a message count is invalidated for some reason (perhaps because the
periodic timer has run), the GUI would not show the number of message at all.
This is suboptimal; in the name of getting a more accurate result in future,
what we get is that the actual value disappears for a while. This change makes
sure that we never forget the old data, even when asked for the new ones.
Do not claim the numbers are fresh when loading from cache

When a list of child mailboxes is loaded from the cache, it used to be shown as
grayed-out to make it obvious that the value might very well be stale. The
recent changes made them appear normal, which might be confusing.

We're cheating in this commit -- the value is marked as loading, so it will be
again shown as grayed-out, but there is no matching network request. Instead,
the code knows that the list of mailboxes will be replaced when the LIST
response arrives.
Merge branch 'bug-332113'

BUG: 332113
REVIEW: 116794
IMAP: save the number of unread/... messages during every mailbox sync

The sync state contains a ton of properties which are not critical for mailbox
updates, but are used by the GUI when showing states of the mailboxes. As it
happens, these numbers were not getting updated at the time the mailbox state
itself was recalculated and pushed to cache.

What should be done of top of this is saving the numbers whenever the STATUS
response arrives. Any change doing that must make sure that it does not clobber
the important SyncState members which are used for synchronization, though.
refactoring

This will become useful in the next commit.
IMAP: store the results of STATUS queries into the cache

See comments inline for why it's important to *not* save EXISTS, UIDNEXT and
other sync-related data. We're saving just those bits which are useful for the
user, but *not* critical for the sync.

In future, this might be extended to also save the total number of messages, but
if this ever happens, it MUST NOT go into the EXISTS field or mailbox syncing
will be utterly broken.
Merge branch 'bug-332113'

REVIEW: 116801
net: Split the network session management into an abstract interface and an implementation
Make it possible to work even when system claims there's no network

Guess what kinds of features Trojita gains when I'm travelling on a place.

REVIEW: 116832