this returns compiled site templates, similar to the dialog templates,
which are needed by the test suite to test the site works!

The list of templates gets pushed onto a single file, with the EJS pre-compiled
into functions. Then, in the Renderer, the functions only need to be invoked,
meaning we no longer need the EJS client lib, and don't eval code.

bf146c2 Merge pull request #43 from klrmn/master
cbc4fe0 fix getters

git-subtree-dir: automation-tests/browserid
git-subtree-split: bf146c230b5ea96590c25f8d55c16c57c8240744

* Increase coherency for each of the three modules

If a persona.org account is initially created with a "primary"
address (meaning an address served by a participating IdP, so
persona.org is given an assertion from that IdP as proof of ownership),
the new account will not have a password associated with it. If you then
add a "secondary" address (meaning an address *not* served by a
participating IdP, requiring an email challenge to prove ownership), you
will have to set up a password when you add the secondary. The
establishment of this password should *not* invalidate any sessions that
were set up earlier.

In Bug #2307, this manifested as the first browser (in which the
add-secondary-email operation was started, so it had the old session and
was waiting for the operation to complete, polling
/wsapi/email_addition_status all the while) receiving a "400
Unauthorized" error when the email challenge link was opened in a second
browser (which thus got a new session).

The test for this effect lives in tests/primary-then-secondary-test.js,
which need the same 2-second delay as password-update-test.js (to make
sure that the modified lastPasswordReset time was actually different
than the previous value, so the session really would be expired).

move hash update later in authenticate_user call, as session cookie must be updated for bcrypt hash update to succeed.

Since MySQL TIMESTAMP is quantized to whole seconds, also change tests
to add a 2s stall before changing the password, to make sure
lastPasswordReset gets a new value.

This honors the preceding comment about not gratuitously expiring
innocent sessions. Somehow this clause got lost as I was
merging/rebasing this function.

Specifically this should reduce the work needed by the
'authenticate_user' call by one DB read.

All wsapi operations now require the database (to update+check the
superSessionToken), so some tests that previously expected operations to
succeed without a database now expect them to fail (generally 503).

wsapi_client.js was changed to pass HTTP errors during
/wsapi/session_context back to the caller, so their response code can be
checked, rather than throwing an error (and preventing any other
assertions from being made).

With this change, existing session cookies are invalidated when the user
changes their password. This will also support a "log me out of
everywhere" button, which merely needs to update the superSessionToken
as if the password was changed.

This adds .superSessionToken to all sessions in
wsapi.authenticateSession, and checks it against the database row in
during a new checkExpiredSession() call (run for all /wsapi requests,
both GETs and POSTs).

All database methods which create an account or modify the password were
changed to also set .superSessionToken (to the current time).
updatePassword() added an 'invalidateSessions' argument so passwords can
be rehashed (when the bcrypt work factor changes) *without* invalidating
sessions. Finally, the database added a new method named
superSessionToken() to retrieve the current value, for comparison in
checkExpiredSession().

wsapi/update_password.js is changed to add a call to authenticateSession
after changing the password, to update the cookie with the new
.superSessionToken. This ensures that the user's new session works on
the next call after update_password.

Database rows that don't have a superSessionToken (created before the
code was upgraded to include this change) will not enforce
session-checking, so user sessions will not be spontaneously expired
when the server is upgraded past this revision.

After the user is authenticated, we might update the hashed password if
the bcrypt work factor has been changed. To simplify the code in
preparation for later changes, this patch extracts the updateHash() code
out to a separate function.

Note that this function must run *after* the `res.json()` call for two
reasons. The first is to avoid slowing down the client (send answer
first, do work later). The second is to get the right session cookie
into the POST that we send to ourselves (to /wsapi/update_password) that
does the actual hash updated. The session is updated in
wsapi.authenticateSession, but the cookie isn't regenerated until the
call to `res.json()`, and the POST is sneakily grabbing the cookie out
of the response's Set-Cookie header to copy into the request-to-self.

This includes an error-handling argument to the callback.

* Change the last bcrypt.get_rounds to bcrypt.getRounds.
* Remove the bcrypt require from tests where it is not needed.
* Remove exports.get_rounds from bcrypt.js, it has been deprecated.

this adds Windows support to bcrypt, as long as you're
using nodejs >= 0.8.5

fixes deprecation warning since newer bcrypt has new API

* Remove the signup page and all remnants of it.

* Useful for when running unit tests on testmob.org.  Unit tests and code need to be embedded in an iframe.

audit and simplify logic in email_for_token to return proper hint to frontend on whether they should get a password from the user and forward it along with the 'complete' request during verification process for acct creation, password reset, email addition, and email re-verificaiton

Rather than going straight to the quick setup, we should link to somewhere that
gives a little more context.

Ensure that when a user verifies in a different browser than what they reset their password with, they must authenticate to complete the verification

- Windows doesn't have signals, so process.on("SIGINT") throws
- changing process.env.PATH is a bad idea