The backend object stores the state of the backend associated with an
account.
Hide the backend object between a mutex, in order to be able to share it
with threads in the next commit.
The operation() method on the MailBackend trait returns a trait object
that can read or modify an Envelope directly from the backend. This is
used to get eg the envelope's text, or set flags. It has two arguments,
envelope hash and folder hash.
Only the Maildir backend needed the latter argument, and it can be replaced with a dictionary to match envelope hashes to folder hashes within the Maildir backend.
Envelope can now only be accessed from within a RwLock. Two new structs
are introduced: EnvelopeRef and EnvelopeRefMut. These hold a reference
to an Envelope and the mutex guard that keeps them alive.
This change allows sharing of the envelopes hash map amongst threads.
Add a boolean field to accounts that states if the account can be
accessed. Local backends (Maildir/mbox) return true every time, but
remote backends (IMAP) may not. Accounts start as offline and then get
initialised when their status goes to online. Right now if an IMAP
account startup but later get offline, there are crashes. With this
change the account can be switched back to offline when that happens.
If Sent folder wasn't correctly configured, the sent message would be
lost. With this change it tries these folders in this order:
1. Sent
2. Inbox
3. Any other normal folder
The check is done by looking at the special usage metadata on each
folder. If everything fails, the message is saved in a file in the
tmpfs.
Send an update event even if user's configuration has turned off
notification for this special event. This happens if the entire folder
is set to `ignore`, or when a particular thread is snoozed. In every
case we would want the UI to update.
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.
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
snooze field translated to whether the user wants to be notified of new
email in the thread or not. This is toggled with an (temp) EX cmd: `toggle_thread_snooze`
closes#112
Manos Pitsidianakis