Previously even a non-initialized (and non-running) loop was
misinterpreted as existing.  Thus actions were not executed, but
scheduled, even if not loop was active.

This caused `matrix_commander` and probably many internal features to
break.

Previously we used a regular expression for determining the proper
places for version replacements.
But for some mysterious reason, the regular expressions are not working
anymore (and according to bumpversion's source code they should have
never worked).
Weird :(

Let us just rely on the likely assumption, that only one occurrence of
the version string exists in each file.

This test targets another case where we use soft-delete. This seems to work already.

Refs #753

Gestalt.get_data() returns all data regarding a gestalt. This includes authored contributions. It is used to set an alternative author upon deletion of the gestalt.

Up to now deleted contributions weren't respected by get_data(). Now we include them by adding a new manager to the contribution model and using it explicitly in get_data().

A regression test is included.

Refs #753

Closes: #748

Some special cases were not handled up to now:
* an absolute path (`/group/article_slug/`)
* a path starting with a username instead of a group

Closes: #751

Closes: #752

The class was never used at all.

This simplifies the code for functions dealing with users, groups and
content.

Previously we used `asyncio.run` in a few place (e.g. in signal
handlers).
But this conflicts with the recently introduced cachalot, which relies
on async function calls for cache invalidation.
Thus signal handlers may be called within a running event loop.
We can detect this now and handle it safely.

Run  in order to
interact with the MatrixCommander bot on a console instead of using a chat room.

This allows to change the "public" state of an association between public
and private.

Due to the shift of user handling from uwsgi to systemd/sysvinit, the
relevant settings changed their name.

* we want to wait until the app is loaded
  ("daemonize2" instead of "daemonize")
* the "daemonize*" options expect a value (the log file) as an
  additional argument

Previously we switched the user context via uwsgi.
This causes problems with creating directories and managing their
ownership (e.g. `RuntimeDirectory` in the service unit is owned by
root).
Moving the complete user handling to the service unit (or sysvinit)
removes this problem.
Now the uwsgi instance is executed in the context of the target user.

Previously the "ExecStartPre" was interpreted as a single command (not a
line to be executed by the shell).
This resulted in a failure when starting grouprise.

Currently two layers of rotation are applied:
1. uwsgi rotates files after reaching a configured size limit
2. logrotate rotates and compresses files every morning

Thus the uwsgi rotated log files remain in the filesystem and need to be
removed manually.
Instead we should just stick to logrotate - this guarantees the absence
of stale files.

Previously a stracktrace was emitted in case of a `ConfigError` exception
during the configuration loading procedure.
Now we handle this exception and reduce the output noise to the minimum.
This should improve readability.

The previous behaviour (raising `ConfigError`) instead of emitting the
error and exiting, can be restored by setting the environment variable
`GROUPRISE_EXIT_ON_CONFIG_ERROR` to `0`.

Previously the absence of any configuration file resulted in the
following error message from Django:

  The SECRET_KEY setting must not be empty.

This was rather misleading.

Now a relevant error message is emitted instead.

The Matrix Chat application adds a few more requirements and thus
complicates the initial setup for local development.
Thus we keep the settings minimal and Matrix disabled.

Now a link to the room is visible at the end of the frontpage.
This should allow users to join the public feed channel on their own.

Closes: #745

Links to Matrix rooms are customized based on the currently
authenticated user.
The resolution of these links was broken since v4.3.0.

Previously all notifications were sent to the recipient of the first
message of the discussion.

Closes: #746

The database migration is only relevant, if the optional attendency
feature is enabled.  Thus probably it did not cause problems for now.

It is now possible to select the `matrix_chat` backend "console" in the grouprise
configuration:
```yaml
matrix_chat:
    backend: console
```

This simplifies testing for matrix chat features and it can be used for
addings tests.