Previously, we were sending the key attached as long as the contact
hasn't replied back. But with new key replace scenarios, we need to updated
the contact keyring with the new key.

We can implement autocrypt or similar in the future, but for now, let's
send the key attached on every email.

- Resolves: #9030

for some reason the implementation was returning a list of default flags
for every mailbox, that's incorrect according to the spec.

we have the plan to implement special mailboxes soon, but for now I'm
merging this as it's needed to get nylas prototype working.

- Resolves: #9031

When content-type was set in the message headers instead of the
MIMEPart (e.g. when not using MIMEParts in the message) bitmask would
ignore it and add the content as text/plain. This caused problems with
Nylas.

To fix this, if the message is not Multipart I'm keeping the
assumption that everything is going to have the maintype of "text" but
copying the subtype from the original message.

This also decodes the original message's payload before attaching the
old content to the new message to make up for the loss of encoding
information.

-Resolves: #9064

we're doing something that shouldn't be done, that is relying on private
methods of the imap server implementation.

until I get to cleanup properly and submit patches for the several things
we're patching in the imap server implementation, keeping up with the
evolution of the imap server implementation is the only thing to do.

specially when we want to get 0.10 out of the door asap.

This is required for Nylas to be able to send emails though bitmask.

node-mail chokes if we don't.

- Resolves: #9003

We were encoding some parts as base64 and others with our manual
encoders. Let's not do base64 and use the email standard library
encoders instead.

- Resolves: #8957

Deal as well with sending key if key is outdated in the providers nicknym.

- Resolves: #8819, #8832