Deprecate or implement internal rate limiting?

[udoprog]

182 was fixed, but I didn't implement rate limiting using burst windows. As per the comment in #184, I raised the question whether this project should provide a built-in rate limiter at all or if we should encourage the user to use an external project like leaky-bucket (full disclosure: my project).

The following is an example of how an external rate limiter is used for anyone who is curious. Unfortunately this hides a lot of utility functions of Sender (like send_cap_req) and it's not straight forward to make async functions like acquire below pluggable. async functions are not supported in traits, nor do we have existential types yet so the anonymous future can be named.

The benefit however is that the rate limiter is an async function that can be await:ed at any point. You have full control over its configuration, use, and implementation. Rate limiting happens before the send is buffered which makes sure that the rest of your application is back pressured when necessary.

use anyhow::Result;
use irc::{Message, Sender};
use leaky_bucket::LeakyBucket;

struct RateLimitedSender {
    sender: irc::Sender,
    rate_limiter: LeakyBucket,
}

impl RateLimitedSender {
    pub fn new(sender: Sender) -> Result<Self> {
        Ok(Self {
            sender,
            leaky_bucket: LeakyBucket::builder()
                .max(100)
                .refill_interval(Duration::from_secs(10))
                .refill_amount(100)
                .build()?,
        })
    }

    pub async fn send(m: impl Into<Message>) -> Result<()> {
        self.rate_limiter.acquire(1).await?;
        self.sender.send(m);
        Ok(())
    }
}

[udoprog]

Related: #191

[aatxe]

I'm fine with presenting the set up for rate limiting differently (including having it be more directly optional), but I'd definitely like to include an out-of-the-box solution within the IRC crate if possible.