If an email is removed by an outside actor, it is marked as removed.
Renaming files first send a Remove event and then a Rename one. So if a
removed email turns out to have been renamed by someone else, issue a
Create event to get it back.
Depending on the insertion order of folders which is non-deterministic
because it relies on the kernel's scheduling of parsing threads, the
listing the user sees might not be up-to-date because later thread
updates are never broadcast. This results in inconsistencies between
threads and mail listings when a thread's root envelope was part of a
not broadcast update leading to `key not found` panics in a listing's
hashmaps.
Remove events almost always come immediately before Rename events,
showing that the previous name of a file is removed and then renamed.
Keep proper tabs by marking removed paths instead of actually removing them.
'\n'
when an empty header is last, the rest of the body keeps getting parsed
as headers. when header starts with '\n' because the value is long, the
value gets parsed as a name and the header parser fails.
closes#100closes#101closes#122
Check subattachments in has_attachments check.
Instead of getting a flattened attachment view of multipart/mixed (eg
[multipart/mixed, text/plain, text/plain]) get only the subattachments
(eg [text/plain, text/plain]). Don't count text-only multipart/mixed as attachments
Each account had one mailbox per folder, which had one associated
collection. Now each Account has one Collection for all folders and each
Mailbox object holds only the hashes of each message.
Collection also gets Threads for each folder in order to mix messages
(ie from/to Sent folder).
Insert Sent emails in chronological order
if inserted unsorted, mails a, b with a happened-before b, might never
get added.
Fix multiple insertions in ThreadTree upon insert_reply
insert_reply was creating multiple copies in threading