Changed internals so trust levels are referred to with
TrustLevel[1], TrustLevel[2] etc.
This gives us much better flexibility naming trust levels, these names
are meant to be controlled by various communities.
This commit heavily refactors Email::Receiver to both better handle
different emails and improve testability.
A primary focus of the refactor is reducing the usage of class
variables, in favor of actually passing parameters - making it possible
for multiple tests to use the same Receiver instance.
The EmailLog reported when a topic is created is reflected to put the
user's email in the to_address field, instead of the system address.
The discourse_email_parser function is renamed to
discourse_email_trimmer, and additional stopping conditions are added to
make up for EmailReplyParser's inability to deal with html at the start
of a line.
The force_encoding calls are refactored out to a 'fix_charset' method.
parse_body is renamed to select_body, and the scrub_html method is
dropped in favor of the new HtmlCleaner class.
A new parse_body method is added, which performs the job of the removed
lines of code in the 'process' method.
EmailUnparsableError is redefined again, to be encoding errors (when the
declared encoding is not what was delivered).
This class is in charge of stripping out most of the crap from the HTML
portion of emails that email clients generate, so that it can be sanely
post-processed for signatures and quoting boundaries.
A failure condition is eliminated where a topic would be created, but post
creation would fail, leaving the forum with a topic without any posts.
By asking PostCreator to create the topic instead, inside of its
transaction, this failure condition is eliminated.
Additionally, attachments are restored to working status. Previously,
the attachment code would build up the post raw, but then drop it and
not do anything with the result (creating orphaned uploads). By actually
placing the raw value back in the options hash, it is included in the
created post.
Use "Site Name <>" for the Reply-To header when the reply is to the site or a public topic.
Use "username <>" for the Reply-To header only when the reply is to a private message topic.
