Add backend support for email address validation.

This modifies how POST /user/:userid works, so that the request is
stored in the local sqlite database, with LDAP unchanged in regards
to the email address. Such requests can be cancelled by another POST
which contains the original address. These requests also email the
new address asking for confirmation that it exists.

Add a new GET /verify/:email:code endpoint, which is deliberately
not documented as part of the API. This is the target used in the
emails sent to the new address, and it is this endpoint which, when
given the right verification code, will actually modify LDAP with
the users new email address.

Also bump libnemesis to use a new property for the users' first name.

Note that, for the moment, this only applies to changes to existing
users' email addresses.

Change-Id: Ibaf5f2913e69a374c63f3c1b3e9a7967a2d916f0
Avoid claiming the current email is also new.

Detect that the current email address is the same as the one in the
current request for a change, and don't put out the new_email key in
such cases. This is actually a valid state to be in - just after a
change has been completed, the request is left in the database.

I've decided to leave the requests in place to cope with the user
clicking the link several times -- this ensures that they just get
the success message several times.

Change-Id: I7103aee14721df243a3bb5c2e3a2624e492e6dc5
Add frontend support for email validation.

This modifies handling of the user edit view to not send the new_email
field unless it's actually different, and to have a note about any
pending email change. If there is a change pending, a button which
cancels that change is also shown.

Change-Id: I248612c4a29e4d289fe8337b719abd1495b20df1
Use the username, not email, as the lookup when verifying emails.

This makes more sense, since this is the key in the database, as well
as because usernames are unique, while we don't (at the moment) have
anything to prevent two users having the same email address.

Change-Id: I32efa3f8f5f988299ee8cdcf92652c9eb49a553e
Move useful helpers into test_helpers.

So they can be re-used elsewhere.

Change-Id: I4fc3622d7466010f54a525305a92355282b4fa67
Remove redunant not-apache check.

This was intended to ensure that the instance being tested was using
the same source as the instance running the tests. However, this isn't
contingent on it not being run against apache, so the check was worthless.

Change-Id: I783c3be8ab34b73a13de18e78f3a945f9d459295
Prefer setUp/tearDown to doing this in the tests.

Change-Id: Ic5177a065d8223f4ec162952cab57549133ee218
Remove redundant semi-colons.

These aren't needed in python, not sure how they got there.

Change-Id: Ia684c5b7cbacbc953f3980af67dab007105258ae
Add a wrapper class around the registrations table.

Create a base wrapper class, and a specialisation for it that uses
the planned schema for automatic account creation. Also tests.

Note that neither this class nor its tests will work until the schema
changes are made.

Change-Id: Idb9854315a3958d861d4860b8ff64d6363ac31df
Add assertion for clarity.

Change-Id: I31e75da9466c196fb1f4ac0a1dde204636c43ff6
Remove debug print.

Change-Id: Id011f7464b2b6c1217bf100f4aa5f0e337b36c69
Have /registrations create placeholder accounts immediately.

This partially replaces the previous functionality of waiting for a
Blueshirt to manually create the accounts. We now create the account
and email the user an activation link (the endpoint for which is not
yet implemented).

Change-Id: Idc10d3bf98aceb6b464a7d0c277b69ee006ea407
Also email the teacher about the new account.

Modify the dummy mailer & add a helper to cope with a single request
sending multiple emails, and ensuring that their order is predictable.
Also update the spec to mention the emails that are sent during
the registration request.

Change-Id: Ifd200bc4fe40f9ddbefed777f05ced83650d6f6d
Move helper method to common location for re-use.

Change-Id: I64d3d73ae098652d115fb130f99007857c54ebcb
Make it possible to remove a registration entry.

Change-Id: I565733b3042e6f1a33cd90586ab5e9edf66f907b
Implement the account activation endpoint.

This provides most of the desired implementation plus tests. Users
can now click on the links sent to them whent the team-leader registered
their accounts & get to a page which makes the account usable & tells
them their new password (and to go change it).

Things it's missing:
* expiration of the activation links,
* notifications back to the teacher (either for expiration or activation)
* the wording in the emails and success page need review

Change-Id: I15f5a6c578d43f550ca8308672698bd1107ce3c2
Remove the obsolete register_user helper.

User registrations are now handled by the PendingUser class & LDAP
interactions via libnemesis, so this isn't needed.

Change-Id: If07045b21d714dc7509393d9b3843bb1482191b3
Move duplicate setUp method to helpers, rename.

This also avoids it being run just because it happens to have the
right name.

Change-Id: Ibd6da32505a4e25dcbe03faa32ab6eb018c1e638
Ensure user removal includes from any groups.

Otherwise, we end up with colleges which claim to have a non-existent
user as a member, which then throws all sorts of exceptions.

Change-Id: I4557928f90b7ea3a18405d06e53f5d74173219d8
Have these tests use a unique username.

This is easier to pick up on when things go wrong.

Change-Id: I7fd54f77c55b661aff1948c1e570a094d11417ef