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
Remove obsolete FIXMEs

These are OK, they are guarded by the dieIfInvalidMailbox() at the top of this
method.
refactoring: match the name with reality

This function *used* to be called when the conn failed, but it has behaved
differently for more than year -- see commit
037f293690365d9f802698930ea82269e8bc005b.
Merge branch 'networksession-optional'
IMAP: do not leave lingering tasks behind when mailbox syncing fails

When the ObtainSynchronizedMailboxTask failed, the waiting KeepMailboxOpenTask
would not unregister itself from the Parser's maintainingTask, and therefore
further tasks kept getting queued "behind" this KeepMailboxOpenTask which stuck
for all practical purposes.

This does not fix #320713 (no UI popup is shown), but at least it makes sure
that further activity can be resumed. A proper indication should be added,
definitely.

CCBUG: 320713
tasks: Better propagation of the reason why this task failed

My original idea at the time this code was written was (IIRC, it's been ages)
roughly something like "well, whatever, use specific signals for propagating
each and every possible error". This was never implemented, of course.

Now, some errors arguably deserve a dedicated signal, but in other circumstances
the fact that something failed is enough; the remedy is usually the same anyway
-- either give up and tell the user that she's got bad luck, or try again later.
Now, it is still useful to at least show the reason to the user. What is missing
here is a piece of code which will let the user know that his mail won't load
because the mailbox couldn't be synced. This will have to come later.

In the meanwhile, let's keep track of the error message so it isn't lost. My
current motivation for this is that the communication between the KeepMailboxOpenTask
and the ObtainSynchronizedMailboxTask uses the standard Tasks API, i.e.
signalling failure via the failed() signal. Instead of extending the API to be
"magic", better add the message to the existing channels.
IMAP: better error handling for further arrivals after initial sync

CCBUG: 320713
IMAP: Scream loudly when mailbox cannot be opened
Merge branch 'bug-320713'

BUG: 320713
REVIEW: 116834