py3: decode email headers with mail.headdecode() in notify extension

py3: use stdlib's parseaddr() to get sender header in notify extension In Python 3, email headers are unicode string so using stringutil.email() will not work as it compares with bytestring. So let's use email.utils.parseaddr() from the stdlib which has a consistent behavior across Python versions. The same is done in patchbomb extension already.

py3: use a BytesParser in notify extension This is the first step to make the "long line" case in test-notify.t pass by fixing a UnicodeDecodeError on Python 3. We alias a parsebytes() in mail module, similarly as we already have a parse() function for Python 2 and Python 3 compatibility.

py3: fix headencode() with display=False We previously called str() on a email.header.Header object. On Python 2, this returns a bytestring and the __str__ method is actually an alias to .encode() method. On Python 3, __str__ does not perform encoding (and returns a unicode string). To keep a consistent behavior across Python versions, we explicitly use .encode() and we wrap the result with encoding.strtolocal() to get a bytestring in all cases. As a side effect of forcing bytes conversion, we need to decode back in _addressencode(). This is to make test-notify.t pass on Python 3. Also note that headers are now encoded in some patchbomb tests; this is because the charset is not always "us-ascii" ("iso-8859-1" otherwise) on Python 3.

mail: catch LookupError in headdecode() We already catch this exception in _encode() (called by headencode()). It gets raised when running test-notify.t with Python 3.

py3: account for extra line break in email headers in test-notify.t Long headers appears to be wrapped with new lines. In test-notify.t, we have a "filter.py" that replaces "\n" by " ", so we get an extra space in a Message-Id with a long value.

py3: use as_bytes() method of EmailMessage In Python 3, as_bytes() corresponds to as_string() in Python 2.

py3: use %d instead of %s when formatting an int into a bytestring The latter wasn't noticed before since no tests exercise --confirm at all, let alone on an existing DREV. The former is only hit during an intermittent network issue during amending at the end of a phabsend, so doesn't seem testable. Differential Revision: https://phab.mercurial-scm.org/D7153