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]>

Fixes #455

Fixes #282

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

Planning to use it for sensitive operations (add/remove security keys),
change email, change password, close account.

The decorator sends a six-digit confirmation code to user's email
and renders a form for entering it back. If the user enters the
correct code, the decorators sets a sudo=active marker in
user's session, valid for 30 minutes.

They have the default values and so are redundant.

When sending email using Django's default email
backend (SMTP), and if there is a network issue, the backend
can throw SMTPServerDisconnected.

This commit adds a retry logic which retries sending the
email two times when SMTPServerDisconnected is thrown.

Normally, when a webhook call fails (timeout, connection
error, non-2xx response), the HTTP request is retried up to two
times (so up to 3 times total). This is useful when sending
actual notifications, in case the webhook target has a temporary
glitch.

When interactively testing a webhook integration
("Send Test Notification" in the
"Integrations" page), we would prefer to see any errors ASAP
on the screen instead of retrying and so possibly swallowing them.

One specific use case is webhook targets that take long time to
generate a response. "Send Test Notification" is synchronous,
meaning that the user could be stuck for
5 x 3 = 15 seconds waiting for the  test HTTP request to time out
three times.

Fixes: #429

In the "Update Check" API call, if no fields have changed,
don't save the changes to the database.

Fixes: #440

Fixes: #435