bug: Rate limiting is at the back of the send queue

[TheDaemoness]

🌧 Describe the problem

girc's rate limit is checked before pushing a message onto the send queue tx. This means if the connection stalls for long enough for tx to fill up with 6 messages or more while otherwise obeying the rate limit, it will likely flood itself off the moment the connection recovers.

Additionally, girc does not provide a mechanism by which a user of girc can add their own rate limiting in the correct place in sendLoop.

⛅ Expected behavior

Any send rate limiting should be checked at the point where messages are popped off the send queue. Additionally, it should be possible for users of girc to introduce their own mechanisms for rate limiting, as girc's rate limit is hard-coded to be more generous than recommendations from RFC1459 (TODO: future issue).

🔄 Minimal reproduction

No response

💠 Version: girc

any

🖥 Version: Operating system

other

⚙ Additional context

Issue is architectural and seems to exist for all versions of girc with rate limiting.

Rate limit occurs here: https://github.com/lrstanley/girc/blob/e3e8859db96adb4a9f66702f8a50f5933fbc0949/conn.go#L445-L463

write pushes to tx here: https://github.com/lrstanley/girc/blob/e3e8859db96adb4a9f66702f8a50f5933fbc0949/conn.go#L484

tx is popped and written in sendLoop here: https://github.com/lrstanley/girc/blob/e3e8859db96adb4a9f66702f8a50f5933fbc0949/conn.go#L514-L544

🤝 Requirements

• [x] I believe the problem I'm facing is a bug, and is not intended behavior. Post here if you're not sure.
• [x] I have confirmed that someone else has not submitted a similar bug report.