Rewrite the MQ sender code to make it resilient towards nonresponsive MQ brokers

[oyvindhagberg]

The original comment: #473 (comment)

Some downsides to this implementation:
if the message broker is having performance issues, it will add latency to all model changes / API requests
best case: the connection is retried ten times
worst case: the connection hangs, waiting for a timeout, ten times
if the message broker is down, messages are silently discarded

Suggestion:
add an intermediate Notification model for serialized message data
change the signals to create Notification objects
add a long-running process (via a management command) that:
selects the N oldest notifications
publishes them to the message broker
deletes the notification if successful
sleeps, repeats
With this, an auto-incrementing primary key could be used as the message ID.

[terjekv]

@ponas / @oyvindhagberg, is this a candidate for a celery queue of some sort? It'd require redis though. Probably easier to do it ourselves.

[terjekv]

https://django-q2.readthedocs.io/en/master/index.html with https://django-q2.readthedocs.io/en/master/configure.html#orm-configuration might be a viable option. The real question is if the load impact on our DB is a problem. I severely doubt it will be, but yeah.