Do not queue Have/Bitfield messages while peer is choked

[coderabbitai]

Context

This issue tracks a problem identified during review of PR #181.

Reference: #181 (comment)

Problem

The current implementation in crates/libtortillas/src/peer/actor.rs queues all non-request messages when a peer is choked. This incorrectly delays PeerMessages::Have and PeerMessages::Bitfield messages.

Choking only blocks our requests; other control messages must still flow. By funneling everything through the queue, PeerTell::Have and PeerTell::HaveInfoDict now stash their updates until the peer unchokes us. In practice, a peer can keep us choked indefinitely, so they never learn we completed pieces (and the cap silently drops older HAVE signals). This breaks tit-for-tat, because the remote never requests data from us.

Proposed Solution

Keep queueing for the traffic that really needs to be deferred, but bypass it for piece-advertising messages. The send_message function should:

• Continue to bypass (return early) for Request messages when choked
• Send Have and Bitfield messages immediately, even when choked
• Queue other messages as currently implemented

Location

crates/libtortillas/src/peer/actor.rs around lines 292-306 in the send_message function.

---

Requested by: @artrixdotdev