Allow password reset even if user has never confirmed their email

Overview

A common situation is that users fail to click on their account creation link within 72 hours. What should happen: User contacts Epilepsy12 who navigate to the user in the platform -> edit user -> click on reset password This triggers a password reset email with a token to the user who clicks through to set a password This pathway has been retested and works. What actually happens: User does not contact Epilepsy12 team as directed as does not read the email. User navigates to password reset page and requests new password. Because the user does not yet have a useable password, no email is sent - this is django stock behaviour. There is no messaging to the user to say this, so frustration follows.

Proposed solution offered in this PR

user account created by their centre lead clinician. An email is sent out with updated details on steps to take to confirm their email in future if they do not click on the link within 72hrs
user fails to confirm account within 72 hr and enters the gulag Two options then result: Option One
1. user contacts epilepsy12 who navigate to user account in the platform - this is the original expected workflow. E12 admin click on the resend email button which only appears for users who have not yet confirmed their accounts. The title of this button has been clarified to Resend Account Confirmation Email.
2. User gets email with fresh token and has a further 72 hrs to confirm account and set password. User has escaped the gulag. Option Two
3. User does not read any of the emails and navigates to password reset, or reads the original email with the expired token, and follows link to reset password
4. User receives email with reset password link and confirms email as well as resetting password. User has escaped the gulag.

Along with this small change in workflow, better signposting in the user table has been added, where a blue target appears next to the user if they have an active account (all accounts are active by default) but have yet to confirm their email. This is replaced by a pink tick if email has been confirmed. The popups have also been changed to clarify the users status.

Implications

Currently the email confirmation step is controlled by E12. This new work flow gives control for the email confirmation step to the user.

The alternative solution would be to retain the current work flow but institute better messaging in the emails and on the login and password reset screen directing users who have not yet confirmed their accounts to contact E12 and ask for the account confirmation email to be resent.

The only implications of this new proposed workflow are possibly that is a little less secure. In either situation, the only way an account could be created by a bad actor would be for them to intercept the emails or have access to the user's email account. The current workflow allows an E12 audit team member to have communication with the user wishing to confirm their account as an extra layer of security that they are happy the person is who they say they are. In the new work flow, a user that has access to an email address in the platform can reset the password and confirm the account in one step.

Code changes

The standard django ResetPasswordForm has been subclassed and the get_users method has been overridden to return all users with a matching email, so long as they are active, whether they have useable passwords or not. This class is used by the reset password view.

Some wording changes to the emails sent have been made, and to the create user form.

Related Issues

Closes #1039

rcpch / rcpch-audit-engine