Previously, I had changed the default value to "", to force
users to set the SECRET_KEY value (the app refuses to start
if SECRET_KEY is empty).

The problem with that is, out of the box, with the default
configuration, the tests also don't run and complain about the
empty SECRET_KEY.

So, a compromise: revert back to the default value "---".
At runtime, if SECRET_KEY has the default value, show a  warning
at the top of every page.

Fixes: #467

The initial implementation was just calling signal-cli directly
using `subprocess.run`.

Going with DBus makes it easier to shield signal-cli from the
rest of the system. It also makes sure the signal-cli daemon is
running in the background and receiving messages. This is important
when a recipient does the "Reset secure connection" from the app. We
must receive their new keys, otherwise our future messages will
appear as "bad encrypted message" for them.

Fixes: #428

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

They have the default values and so are redundant.

This change allows SMTP configuration via email, but users can
still choose to configure the settings directly in local_settings.py

When running the migration command from outside of the application directory the sqlite database is created in the current working directory at the time of the command being executed. This commit updates the file path to be relative to the location of the settings file.