Feat(watcher): add event retry queue

[amirRamirfatahi]

bin to handle failures without disrupting the watcher's flow of reading events.

Pre-submission Checklist

For tests to work you need a working neo4j and redis instance with the example dataset in docker/db-graph

• [*] Testing: Implement and pass new tests for the new features/fixes, cargo test.
• Performance: Ensure new code has relevant performance benchmarks, cargo bench

[SHAcollision]

Hey @amirRamirfatahi, thanks for putting together this PR!

A couple of different things here intertwining in this PR with different value/priority: 1. error curation (we need now) and 2. retry queue (future need)

• Error Curation: It could be useful to start curating a list of errors to identify watcher bugs when handling real user events. The approach in this PR has some potential, though dumping detailed errors straight to the terminal and manually collecting them might be the simplest option for now. Still, feel free to experiment and collect some Errors/bugs that we can act on.

This relates directly to #169 (comment) and I would say this is pretty high priority. Quoting from the linked comment:

This is a janitorial task: compile an Issue with unexpected errors, their logs and if possible, how to reproduce them.

• Retry Queue: A retry mechanism could be handy in the future, but it feels premature at the moment. We’d need to carefully define conditions for retries, e.g., "Homeserver not found" (retry in X hours) vs. validation errors (never retry). I think we can only be careful enough on defining "what to retry" after we make an exploration of the Errors we get in the watcher. That said, when we scale to multiple homeservers, the retry service concept will definitely be worth revisiting. Low priority at the moment.

I think we can let this PR in paused until the complexity is actually merited, as going in the weeds to review in depth, solve tests issues and merge this code subtracts work-power from other tasks.