Redirect unauthenticated users to the sign in page
instead. Rationale:

- The content on the welcome page is what often belongs
  to a separate "marketing site". The marketing content
  is of no use on self-hosted instances, which typically
  have new signups disabled and are for internal use only
- (the real reason, let's be honest) a number of
  self-hosted instances are accessible over the public
  internet. Search engines index the nearly identical
  landing pages and see them as duplicated content.

Fixes: #77

If an already authenticated user visits /accounts/login/,
Healthchecks will now redirect them to their dashboard
instead of showing the login form.

This fixes a security issue:
- attacker can crafts a redirect URL to an external site
- attacker gets victim to click on it
- victim logs in
- after login, Healthchecks redirects victim to the external site

The _allow_redirect function now additionally
requires the redirect URL is relative (has no scheme or domain).

If user has both WebAuthn and TOTP configured,
when logging in, they will be asked to choose between
"Use security keys" and "Use authenticator app".
The "Use authenticator app" is a link to a different
page (/accounts/login/two_factor/totp/). This commit makes
sure the ?next= query parameter is preserved when navigating
to that page.

For reference, the ?next= query parameter is the URL we should
redirect to after a successful login. Use case:
User is logged out. They click on a bookmarked "Check Details"
link. They get redirected to the login form. After
entering username & password and completing 2FA,
they get redirected to the "Check Details" page they
originally wanted to visit.

Fixes: #354

It is obsoleted by Profile.reports

This is in preparation of adding an option for weekly
reports (#407)

Fixes: #486

User handle is used in a username-less authentication, to map a
credential received from browser with an user account in the
database. Since we only use security keys as a second factor,
the user handle is not of much use to us.

The user handle:
 - must not be blank,
 - must not be a constant value,
 - must not contain personally identifiable information.

So we use random bytes, and don't store them on our end.

Changing user's password logs themselves out. To avoid that,
we were logging the user back in right after changing the password.

I recently discovered update_session_auth_hash, which seems to
be the proper way to do this.

Docs: https://docs.djangoproject.com/en/3.1/topics/auth/default/#session-invalidation-on-password-change