Relying on non-stable components is problematic for packaging

Hi! On attempting to upgrade hyperkitty to 1.3.5 I stumbled upon the new dependency on mistune>=2.0.0rc1, introduced in !324 (merged).

While it is of course great to have new functionality included, relying on a non-stable version of a software is a big problem for downstream distributions such as Arch Linux. We currently still ship 0.8.4, as it is the latest stable release and a stable version of mistune 2.0.0 has not yet been released.

Furthermore, a bunch of other software currently still relies upon mistune < 2.0.0, such as jupyter, jupyter-nbconvert, m2r, pcbdraw, python-flasgger and one or all of them may or may not be compatible with mistune >= 2.0.0rc1, which makes "just updating mistune" a non-trivial undertaking.

Given, that hyperkitty 1.3.5 fixes CVE-2021-33038, CVE-2021-35057 and CVE-2021-35058 (https://security.archlinux.org/AVG-2003), I am not very happy about this situation, as it now requires me to shift the dependencies of the above packages around to a temporary replacement package and then upgrading mistune to a non-stable release version. This makes installing the above packages and hyperkitty on the same host impossible using the system package management.

@maxking I see that you have requested a stable version release from mistune's upstream in august. IMHO this and ensuring that there was a stable release should have happened before merging the new feature.

Please consider these types of changes carefully before release next time, as they have non-trivial implications on downstreams.