Make logins case-insensitive

[rebeccacremona]

This PR makes login case-insensitive, and ensures at the database level that no "duplicative" accounts can exist. It cannot be deployed until the existing duplicative accounts are merged, using the code in the former PR and a small amount of manual clean up.

• It adds a new field to our user model, "raw_email", and copies over the current contents of the "email" column.
• Then, it downcases the "email" column and adds a UNIQUE lower(email) index to the DB so that, even if something goes wrong at the application layer, no more duplicative accounts can be created.
• It arranges for the login and password reset forms to downcase the submitted email field during the clean phase, so that logins and password resets are case-insensitive.
• When admins/registrar users/org users add people to groups, it downcases the email they enter, so that the check-for-existing-users step is case-insensitive, and so that, if no existing user is found, the new user is created with a lowercase email address.
• When people sign up by themselves, the email they enter is saved in raw_email as is, and a lowercase version is saved in email.
• When Perma displays the email address or when it sends mail, it uses the raw_email field.

The unit tests are fairly extensive, so I am pretty confident this works as intended.

However, there is definitely the possibility that I am missing something. Can we think of anything I'm missing? Can we think of anything this might break that wouldn't normally be covered by a test suite?

Tentatively closes https://github.com/harvard-lil/perma/issues/3152

NB

This code should not be merged until we are ready to deploy it, just in case.

Before we deploy it, Ben and I intend to contribute a few more bits of code:

• a tweak to the account merging code of the aforementioned PR
• code that will email the merged users, after the fact
• some Salt excitement to make the deployment smoother

I am not marking it a draft, in order to request reviews.

[rebeccacremona]

I tested the data migrations locally with a prod-like dump, and found it to be zippy: like 7 or 8 seconds.

[codecov[bot]]

Codecov Report

Merging #3328 (9ef573b) into develop (6f09766) will increase coverage by 0.09%. The diff coverage is 90.32%.

@@             Coverage Diff             @@
##           develop    #3328      +/-   ##
===========================================
+ Coverage    70.17%   70.27%   +0.09%     
===========================================
  Files           55       55              
  Lines         6977     6997      +20     
===========================================
+ Hits          4896     4917      +21     
+ Misses        2081     2080       -1     

Impacted Files	Coverage Δ
perma_web/perma/admin.py	87.46% <ø> (ø)
perma_web/perma/views/common.py	83.13% <ø> (ø)
perma_web/tasks/dev.py	0.00% <0.00%> (ø)
perma_web/perma/views/user_management.py	94.83% <92.85%> (+0.14%)	:arrow_up:
perma_web/perma/forms.py	95.32% <100.00%> (+0.08%)	:arrow_up:
perma_web/perma/models.py	86.31% <100.00%> (+0.11%)	:arrow_up:

[rebeccacremona]

Note that email isn't included in API results, which means we don't have to worry about email/raw_email in the JS or anywhere upstream.