Fixes: #77

This commit adds a {% absolute_site_logo_url %} template tag.
The tag emits an absolute url pointing to either
SITE_LOGO_URL or to the fallback picture.

The tag is used in base email template, in slack message
template, and in "Add MS Teams" page.

This commit also fixes a couple instances where absolute URLs
were constructed like so:

    {% site_root %}/docs/

This would result in incorrect links if Healthchecks is not
running at webserver's root. The correct way is:

    {% site_root %}{% url 'hc-docs' %}

Finally, this commit removes stuff/logo.svg and
stuff/logo-full.svg. Selfhosted sites should not use the
official Healthchecks.io logos, so no point keeping them around
there.

Fixes: #550

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.

This has dual purpose:

* if user has both WebAuthn and TOTP set up, they can choose
  between the two as equal options.
* we initiate WebAuthn flow only after an explicit user action
  (button press). This may help with authentication failures
  on recent MacOS, iOS and iPadOS versions [1]

[1] https://support.yubico.com/hc/en-us/articles/360022004600-No-reaction-when-using-WebAuthn-on-macOS-iOS-and-iPadOS

Fixes: #354

It is obsoleted by Profile.reports

This is to help troubleshoot 2FA issues without
running manual SQL queries.

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

When an account has a password, replace "Set Password"
button's label with "Change Password"

Cannot use functools.cached_property, as it was added in Py 3.8,
but we support 3.6+

Primary sort key: projects with overall_status=down go first
Secondary sort key: project's name

Fixes: #497

Profile.next_nag_date tracks when the next hourly/daily reminder
should be sent. Normally, sendalerts sets this field when
a check goes down, and sendreports clears it out whenever
it is about to send a reminder but realizes all checks are up.

The problem: sendalerts can set next_nag_date to a non-null
value, but it does not clear it out when all checks are up.
This can result in a hourly/daily reminder being sent out
at the wrong time. Specific example, assuming hourly reminders:

13:00: Check A goes down. next_nag_date gets set to 14:00.
13:05: Check A goes up. next_nag_date remains set to 14:00.
13:55: Check B goes down. next_nag_date remains set to 14:00.
14:00: Healthchecks sends a hourly reminder, just 5 minutes
       after Check B going down. It should have sent the reminder
       at 13:55 + 1 hour = 14:55

The fix: sendalerts can now both set and clear the next_nag_date
field. The main changes are in Project.update_next_nag_dates()
and in Profile.update_next_nag_date(). With the fix:

13:00: Check A goes down. next_nag_date gets set to 14:00.
13:05: Check A goes up. next_nag_date gets set to null.
13:55: Check B goes down. next_nag_date gets set to 14:55.
14:55: Healthchecks sends a hourly reminder.

Fixes: #486

Fixes: #348

* Add HTTP header authentiation backend/middleware

* Add docs for remote header auth

* Improve docs on external auth

* Add warning for unknown  REMOTE_USER_HEADER_TYPE

* Move active check for header auth to middleware
Add extra header type sanity check to the backend

* Add test cases for remote header login

* Improve header-based authentication

- remove the 'ID' mode
- add CustomHeaderBackend to AUTHENTICATION_BACKENDS conditionally
- rewrite CustomHeaderBackend and CustomHeaderMiddleware to
use less inherited code
- add more test cases

Co-authored-by: Pēteris Caune <[email protected]>

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.