[soujasK]

Problem

Removing a reset_peer toxic after it has received data blocks for the rest of its timeout, and so does adding another toxic after it in the same direction. The collection lock is held the whole time, so with a timeout over 25s the API request returns 503 and other toxic requests for that proxy block until the timer fires.

Root cause

After reading the first chunk, ResetToxic.Pipe waits with a bare <-time.After(timeout). InterruptToxic blocks until the running toxic receives from Interrupt, which reset_peer doesn't select on while waiting, so RemoveToxic / AddToxic / UpdateToxic wait for the timeout.

Solution

Select on Interrupt while waiting, and return without resetting when interrupted, the same way slow_close, timeout and latency handle interrupts during their waits.

Verification

• New TestRemoveResetPeerToxicDoesNotWaitForTimeout: a reset_peer with a 10s timeout receives a chunk, then is removed. On main the removal is still blocked after 2s; with the change it returns right away.
• Linux: go test -race for the root package and ./toxics -run Reset (3 runs) pass; golangci-lint v2.14.0: 0 issues.

Compatibility and risks

Removing a reset_peer while its reset is pending now cancels the reset, instead of resetting the connection after the API call has been stuck for the timeout.

If another toxic is added or updated while a reset is pending, reset_peer is restarted and waits for the next chunk before starting its timeout again, so the reset is postponed until more data arrives. The other timer-based toxics behave the same way after an interrupt. Keeping the original deadline across restarts would need per-link state; I left that out to keep this small.

May address some of the reports in #500.