Task: Improve Rate Limiter Handling of Time

[carlaKC]

Description

47 introduced a basic rate limiting implementation with some unit tests, but they're not ideal. One of the main limitations here is around the mocking we have in place for the clock:

• The mock requires that we checkpoint it between calls to set different return values, which requires a mutable reference.
• The mock also doesn't implement clone, so once we create at TokenLimiter we can't checkpoint it (since it's moved on creation).
• To test the rate limiter nicely, we want the clock to be able to return different times.

Steps to Complete

1. Update tests to use a static start time (unix epoch?) rather than the current time.
2. Improve tests to mock out progression of time rather than this workaround, this could either be: 2.1. Update handling of mock to report different timestamps / figure out how to clone + checkpoint afterwards 2.2. Add a duration_since method to the Clock trait, which can be more easily mocked (though still suffers similar issues) - perhaps stealing ideas from LDK

[kannapoix]

@carlaKC (or perhaps @orbitalturtle, who is currently more active). What are your thoughts on using Tokio's built-in testing features(such as advance method)? This approach differs from what you suggested earlier, but it allows us to manage time without relying on mocking.