comments: add changeset author in mail notification subject

In analogy to the handling of comments on pull requests, as changed in
commit d4061c6cc0e2.

notifications: explicitly add author of pull request in invitation mail

When an author of a pull request does not get feedback from any of the
reviewers, he is left wondering whether they got the invitation mail at all.
By explicitly sending the invitation also to the author, he can at least know
if e-mail works at the server side and how reviewers see it.
The mail can also be forwarded as a 'reminder'.

celery: fix send_email to work with JSON encoding (Issue #363)

Long time ago, c935bcaf7086 introduced an optional User object parameter to the
send_email task and used the computed full_name_or_username property. Due to the
magic of pickle, that also worked when using Celery to run the task async.

Now, Celery 4 changed the default encoding from Pickle to JSON, which we
anticipated in e539db6cc0da. That broke send_email in some cases, for example
when a user comments on another user's changeset.

Fixed by passing the "From" name as string instead of passing the whole User
object.

Thanks to vyom for reporting.

email templates: reorder references to pullrequests

The current references to PRs in email templates are:

Pull request from <repo> branch <branch> to <repo> branch <branch>:
<niceid> <title> by <user>

as the first line can become very long and therefore hard to read, a first
step is to introduce a newline before the destination branch:

Pull request from <repo> branch <branch>
to <repo> branch <branch>:
<niceid> <title> by <user>

But it would be nicer if the from/to part aligns more.
Moreover, the most useful part is (hopefully) the PR title, the from/to is
secondary and can sometimes even be inferred from the title and context the
recipient is already aware of.

Thus, this commit proposes the following format:

Pull request <niceid> <title> by <user>
from <repo> branch <branch>
to <repo> branch <branch>


This adds some divergence with the changeset references, which could be
aligned later if desired.

email templates: align word to indicate branches: at / branch

Some email templates use '<repo> at <branch>' while others use
'<repo> branch <branch>'. Interestingly even some txt templates use one and
the corresponding HTML template uses the other.

This commit aligns all uses of 'at' and 'branch' to 'branch' as it is
considered more expressive.
The other choice would also be possible, as long as all users are
aligned.

HTML email templates: make pullrequest title a hyperlink

This commit makes the entirety of PR nice id _and_ PR title clickable,
rather than only the PR nice id.

HTML email templates: restrict amount of visible hyperlinks

Users report that some HTML email templates are confusing due to the large
number of hyperlinks in them. They typically click the first thing they see
that looks clickable without actually reading what they are clicking on,
expecting that it all points to the same thing.

In pullrequest invitations, the pullrequest and changeset URLs should be
clickable, but the source and target repository should not: this is not what
you typically want to see when taking action on this mail.

Similarly in comment emails, the corresponding repository should not be
clickable.

Unfortunately, even if we remove the <a> hyperlink tags on these repository
URLs, most mail clients will still recognize the text as being URLs
and make them clickable anyway. Worse, they will do so in a different
styling than the other links.

Therefore, do add <a> tags in the HTML, but make use of styling like that of
data_style, i.e. regular text color, grey background with dark grey border.
The links _will_ thus be clickable but it will not be as inviting as before,
thus removing confusion.

HTML email templates: don't use link color for non-links

The link color should only be used for actual hyperlinks.
Using it for anything else is very confusing for users.

For text like repository names, branch names, etc. introduce a new style
'data_style' that is normal text with a grey background and border.

HTML email templates: don't use link color for PR descriptions

The link color should only be used for actual hyperlinks.
Using it for anything else is very confusing for users.

For pullrequest mails, the usage of the link color for the PR description
may have been done to separate the description more clearly from the title
word 'Description' above it.
Instead, use a table with grey background similar to how comments are
displayed. This meets the objective of not abusing link colors as well as
clearly separating the description from the rest of the mail.

lib: change &apos; to &#39; to satisfy Outlook HTML rendering

The HTML entity &apos; (') did not exist in the HTML 4 spec [1] and was only
added later.
As Outlook (and Thunderbird) uses an old engine to render HTML and CSS, it does
not recognize this entity and treats it as a literal string.

Therefore, use the equivalent &#39; code which should be recognized by all
browsers, even those restricted to HTML 4.

[1] https://www.w3.org/TR/html4/sgml/entities.html

email templates: add HTML entities to test strings

An issue is observed in Outlook rendering of HTML emails, where the HTML
entity &apos; is not recognized and seen as a literal string.

Add some HTML entities to the test strings to be able to see the issue
(after mailing the resulting HTML to an Outlook client)

tests: notification: clarify that cs_target_repo is a URL

In analogy with the fake URLs used for pullrequest notification testing, use
an URL for cs_target_repo. When testing the resulting HTML in a real email
client, it will become obvious that the mail client transforms URLs to
something clickable, regardless of any present <a> tag.

HTML email templates: Outlook: fix list bullets

The rendering of HTML emails in Outlook is very restricted and based on old
Internet Explorer versions (more or less the same rendering as in Microsoft
Word). To make the Kallithea emails look the same as in the browser, some
adaptations are needed.

List bullets (to identify different changesets in pullrequests) are not
shown in Outlook. In order to fix that, a proprietary CSS property is
required.
Fix found via:
https://litmus.com/community/discussions/752-can-we-use-ul-and-li-in-email

HTML email templates: Outlook: fix width and height attributes to preserve whitespace

The rendering of HTML emails in Outlook is very restricted and based on old
Internet Explorer versions (more or less the same rendering as in Microsoft
Word). To make the Kallithea emails look the same as in the browser, some
adaptations are needed.

HTML width and height attributes do not have any effect, the size is
interpreted as 0px. A CSS-based width and height do work in Outlook and
result in the expected spacing between and within elements of the email.

For Outlook rendering, the CSS variant is probably sufficient, but as it is
unclear how other mail agents will interpret this, leave the HTML width and
height attributes as well.

HTML email templates: Outlook: fix padding inside of action button

The rendering of HTML emails in Outlook is very restricted and based on old
Internet Explorer versions (more or less the same rendering as in Microsoft
Word). To make the Kallithea emails look the same as in the browser, some
adaptations are needed.

The padding inside the button is completely lost in Outlook, the text sticks
to the border. This can be fixed by moving the padding styling from the
<center> tag to the <td> cell.

HTML email templates: Outlook: center action button

The rendering of HTML emails in Outlook is very restricted and based on old
Internet Explorer versions (more or less the same rendering as in Microsoft
Word). To make the Kallithea emails look the same as in the browser, some
adaptations are needed.

One of the problems is that the action button is not centered.
An extra <center> tag solves this issue.

mails: make title in header boxes slightly bolder

In my opinion, the top headers in the new mail styling seemed a bit "thin"
compared to the other headers.

helpers: in urlify_text, use <br> for newlines in pre-formatted text so it can be cut'n'pasted correctly

Before, when copying the preformatted nice looking ASCII-artsy text in a PR or
changeset description from a browser to a text editor, it would be pasted as
text without newline. Simply put, copy/paste ignores that it is inside a <pre>
/ white-space:pre-wrap section.

Instead, translate newlines to <br> which always translates to a newline when
pasted.

notifications: new email templates with html styling

- with heavy interfering and hacking by Mads Kiilerich.

mails: restructure notification mail content

* Mention "The Thing" in the header, link to online version
* Show The Thing
* A dense summary of the essentials of the context below it

The html indentation is odd in order to make the next diff smaller.

The text version is based on:

for a in kallithea/templates/email_templates/*.html; do sed -e 's,<\([^%/>]\|/[^%>]\)*>,,g' -e 's,\.html",\.txt",g' -e 's,^ *,,g' -e 's/}/|n,unicode}/g' $a > ${a%%.html}.txt ; done

tests: update mail template dump test

The combination of 552800808386 and ab29e4c39550 caused incorrect template content.

notifications: tweak PR mail subject lines

The subject line is used for mail threading in gmail and can thus not be
changed without impacting users ... but now we do it.

* The tag '[Review]' is more spot-on than '[Added]'.
* The subject should be short so it fits on one line, so abbreviate "pull
request" to PR.
* Add the PR owner - convenient for filtering comments on own PRs from comments
on other PRs.

email: add relevant title to subject of emails

For comment and pullrequest mails, add changeset/pullrequest title (shortened
to first 50 characters of first line)

tests: introduce tests and reference dump for notification mails

The mails are dumped to a tracked html file:
* changes shows up as diffs and are easy to spot and review
* all mails can easily can be investigated in a browser and checked for content
and consistency

The tests are mocking canonical_url because it has deep dependencies to
pylons.url which requires (thread local?) environment setup that the tests
doesn't have.