Robert Ransom authored May 12, 2014 and Isis Lovecruft committed May 14, 2014

Signed-off-by: Isis Lovecruft <isis@torproject.org>

 * FIXES a problem noted by Robert Ransom (in ticket #5463) with
   adversaries being able to capture a signed email for Alice and resend
   it to Bob to target Bob by having influence over his available
   bridges.

 * ADD a footer to emails, which includes the client's email address and
   a timestamp for when the email was generated.

 * ADD the answer bridge lines to the answer template creation
   parameters, so that the answer string isn't formatted into the
   message after message creation.

Rename email.template functions for adding text. To distinguish them
from the templates.build* functions, which build entire emails. The
following functions have been renamed:

 * RENAME templates.buildCommands()     → templates.addCommands()
 * RENAME templates.buildKeyfile()      → templates.addKeyfile()
 * RENAME templates.buildHowto()        → templates.addHowto()
 * RENAME templates.buildBridgeAnswer() → templates.buildBridgeAnswer()

 * ADD two new unittests: one for missing config settings pertaining to
   email signing, the other for when signing is disabled.

We can't use expired keypairs, and the old testing keypair had it's master
secret key destroyed, so I created a new testing keypair.

 * CHANGE gnupghome/TESTING.subkeys.sec to a non-expired keypair:

   pub   4096R/3F148C21 2014-04-23
   uid                  TESTING (INSECURE!) <bridges@torproject.org>
   sub   4096R/C9CB1DCD 2014-04-23
   sub   4096R/79DEF4D1 2014-04-23

   sec#  4096R/3F148C21 2014-04-23
   uid                  TESTING (INSECURE!) <bridges@torproject.org>
   ssb   4096R/C9CB1DCD 2014-04-23
   ssb   4096R/79DEF4D1 2014-04-23

GPGME was using the process owner's default GPGHOMEDIR directory,
regardless of any keyfiles specified, meaning that if there were any
other non-signing enabled secret keys in the keyrings, and one of the
other keys was first on the secret keyring, that first key would be used
for signing rather than the secret key in the specified keyfile.

 * FIX problem detailed in comment 11 on #5463:
   https://trac.torproject.org/projects/tor/ticket/5463#comment:11

This changes the unittests for EmailServer.getMailResponse() to test
bridgedb.email.server.createResponseBody() instead.

The old bridgedb.EmailServer module has now been divided into several
modules in the bridgedb.email package.

 * FIXES #5463 by adding the last touches for email signing.

 * FIXES #7547, #7550, and #8241 by adding a welcome email which can be
   received by sending an invalid request, or by saying "get help" in
   the body of the email.

 * FIXES #11475 by using the same "How To Use Your Bridge Lines" text
   for TBB/TorLauncher which is used for the HTTP distributor (on the
   website).

 * FIXES #11753 by making email responses translatable. A translated
   response can be requested, for example, for Farsi, by emailing
   mailto:bridges+fa@torproject.org.

This now records how long a client must wait before they are no longer
rate-limited for the email distributor.

In order to use translated strings from the bridgedb.strings module, we
need to pass the namespace parameters (i.e., the arguments in
HTTPServer.py to `template.render()`) from the parent template
(base.html) to the inheriting templates.

While we're at it, we should pass information on the requested lang, so
that translations don't suddenly turn off if you go to a different page,
and info on whether the page should be rendered RTL. This fixes a slight
bug where the pages deriving from
`bridgedb.HTTPServer.CaptchaProtectedResource` weren't being correctly
translated or RTL-rendered when they should be.

And also while we're at it, we should probably not do *anything* inside
of `bridgedb.HTTPServer.*Resource.render_*` methods outside of the
try/except block, because any error will be rendered as a traceback to
the client.

Additionally, we should set the content type and encoding in the headers
of every response before returning it.