channel: Document that send_timeout sends an available message even if the timeout has elapsed

[teddytennant]

What

Adds a sentence to the doc comments of Sender::send_timeout and Sender::send_deadline noting that a non-full channel accepts the message even when the timeout/deadline has already elapsed, and adds a unit test covering that behavior.

Why

Follow-up to #1280, which documented this for the receiver side (recv_timeout/recv_deadline, originally noted in #1245). The sender side has the exact mirror behavior for the same reason: the flavor send implementations attempt the send before checking the deadline, so a non-full channel accepts a message even for a zero/elapsed timeout. The send_timeout/send_deadline docstrings didn't mention it, leaving the send/recv docs inconsistent. This mirrors the wording from the receiver side, adapted to sender terminology.

Testing

Added send_timeout_nonfull_expired to crossbeam-channel/tests/array.rs, which asserts send_timeout(1, Duration::from_millis(0)) returns Ok(()) on a non-full bounded(1) channel (message accepted despite the zero timeout) followed by Err(SendTimeoutError::Timeout(2)) on the now-full channel. It is deterministic: everything runs on one thread and start_send on a non-full array channel succeeds on the first attempt before any timeout check.

• cargo test -p crossbeam-channel --test array send_timeout — 2 passed (including the new test)
• cargo test --doc -p crossbeam-channel — 74 passed (docstrings still compile)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.