back pending rabbitmq messages in postgres to allow for persistent retrying

[baseballlover723]

The core issue with this, is that before, if rabbitmq went down, and then you restarted the modbot feeds container, then it would simply drop any messages it didn't get to sent to rabbitmq.

Now it will store them in postgres instead of memory.

I'm not 100% satisfied with this implementation. It's still pretty fundamentally dependent on using exceptions to blow up, and reconnect to everything as it's recovery method. This means that it'll continue to stop processing db stuff while rabbitmq is down. Which means that if it's down for too long, data will be pushed out of the feed and won't get added to the db at all. Which I don't like.

Tbh, part of me is wondering why I even went for RabbitMQ instead of message queuing through Postgres. But that's already done and this really doesn't need to be so robust.

I think the ideal implementation has RabbitMQ fully facaded and we like keep track of if we know it's up or down. And when we know it's down, we like retry the pending messages before sending off any new messages (so that order is maintained). Tbh, order should not be precisely guaranteed when processing messages, so tbh, even like flushing any pending messages after a success (resulting in 1 potentially very out of order message) I think is as robust as is reasonable.

Idk if I'll actually do that though. I probably shouldn't. We should just not let the rabbitmq container go down for extended periods of time.