* Resolves: #7889

It won't break anymore if the body is None, but will
return an empty body in that case

Related: #7495

In the case of a message with just one non-text attachment, something
has to be returned for the body payload. (For instance, a message with
only one image).

in a previous refactor, we decoupled the incoming mail service from the
IMAP layer. However, this left the IMAPMailbox unable to react to
changes in the underlying collection when a new message is inserted.

in this commit, we add a Listener mechanism to the collection itself, so
that IMAPMailbox (and any other object that uses it) can subscribe to
changes on the number of messages of the collection.

Resolves: #7191
Releases: 0.4.0

in a previous commit, there was a bug inserted in which a key lookup was
being made unconditionally, even when the pending_insert_docs was None.

Releases: 0.4.0

Although this draft-saving feature seems to be somehow brittle, since it
breaks from time to time, the causes are different and subtle on each
case.

This time the bug is related to having the notify_just_mdoc (or
fast_notifies as I'm tempted to call it in the future for more clarity)
set to True by default in the APPENDS.

Fast notifies break the "save draft" functionality because what
Thunderbird does is an Append of the newest message, followed by
deletion of the old message and a SEARCH by Message-ID. For this we need
the headers-doc to be already inserted in the store.

Since the fast-notify makes a *big* difference in terms of insertion
times for serialized appends, I've opted for using a heuristic for
detecting if it's the case of a Draft message, using a mozilla-specific
header. If this is found, we set the notify_just_mdoc unconditionally to
False. We'll deal with other MUAs on its due time.

Releases: 0.4.0

the bug consist on a fetch-while-pending-inserts hanging. the pending
insert dict was not being cleaned up because the lookup for the
Message-Id *is* case-sensitive (in the headers dict).

by using a temporary all-keys-lowercase dict the lookup can be performed
right, and the fetch returns successfully.

at this point there's still a pending bug with Drafts, and it is that
the new version is inserted but the MUA (TB) doesn't hide the older
version (although a Delete flag is added).

Resolves: #7189, #7190
Releases: 0.4.0

- Add errback handling to catch properly errors that were not allowing
  the complete insertion of the parts for a given message. Fixes blank
  attachments and moving of messages to different folders.
- Force overwritting of mdoc when it is a copy. This was avoiding a
  message to be copied back to a folder from where it already had been
  copied to another (since the mdoc was already existing there, with the
  same doc_id, which was forbidding the creation of the new one).
  This case also needs special care in the indexer, since we have to
  delete the old hash entry first.

Closes: #7178, #7158

There's a workaround for "slow" APPENDS to an inbox, and it is that we
have a flag to allow returning early when JUST the mdoc (the
meta-document) has been written. However, this was givin a problem when
doing a FETCH right after an APPEND (with notify_just_mdoc=True) has
been done.

This commit fixes it by making the FETCH command first check if there's
an ongoing pending write, and queueing itself right after the write
queue has been completed.

This fixes the testFullAppend regression.

Releases: 0.4.0