net/tcp/tcp_send: Remove work_available check when updating retransmit timer

[zhekunren]

Problem

The original condition work_available(&conn->work) && tx_unacked != 0
prevented tcp_update_retrantimer from being called when the work queue
was still busy, leaving conn->timer stale or zero. This caused the RTT
estimation to compute a false RTT (m = rto - 0 = rto), creating a
positive feedback loop that inflated the RTO to extreme values (e.g.,
232 half-seconds = ~116 seconds).

Detailed Scenario

1. First send: work_available is true, the condition passes,
   conn->timer is set to conn->rto, and the work queue is scheduled.
2. Second send (work still running): work_available is false, the
   condition fails, tcp_update_retrantimer is not executed, and
   conn->timer keeps its previous value.
3. Third send (work just fired but still unavailable): work_available
   is still false, the timer is not reset; if the timer expires in the
   meantime, conn->timer is decremented to 0.
4. ACK arrives: conn->timer is 0, so the RTT estimation computes
   m = rto - 0 = rto, producing a bogus measurement.

Fix

Remove the work_available check so that tcp_update_retrantimer is
always called when there is unacknowledged data. The decision to re-queue
the work is handled internally by tcp_update_timer. This ensures:

• When the ACK arrives, timer is always a freshly set value.
• m = rto - timer truthfully reflects the actual RTT.
• The bogus measurement caused by timer = 0 is avoided.

[masc2008]

smart fix : )

[jerpelea]

please rename the commit tile to
net/tcp/tcp_send: Remove work_available check when updating retransmit timer

[github-actions]

MemBrowse Memory Report

hifive1-revb

• flash: .text +4 B (+0.0%, 83,412 B / 4,194,304 B, total: 2% used)
  No memory changes detected for:
• arduino-mega2560
• esp32-devkitc
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb