feat: retry manager

[tipogi]

Description

This PR introduces a foundational implementation for the RetryManager. It includes:

Initialization of a message-passing system with a channel (Sender and Receiver).
A RetryEvent structure to represent retryable events, including fields like uri, event_type, retry_count, and optional dependencies or error messages.

Basic methods for:

• Adding failed events to a retry queue (add_fail_event).
• Processing retry events for a specific homeserver (retry_events_for_homeserver)

Motivation

The RetryManager is a core component to handle failed events during homeserver interaction. This initial implementation sets up the required structure and logic to:

• Track and store retryable events.
• Manage retries based on specific homeserver URIs.

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

[amirRamirfatahi]

2 initial comments to think about:

1. Can we use Redis as the messaging queue?
2. being able to identify ghost(?) users.