Stabilize tcp_deferaccept

[JohnTitor]

Close #119639
FCP: #119639 (comment)

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 8 candidates
• Random selection from Mark-Simulacrum, jhpratt

[asquared31415]

I think that the doc comments need editing for grammar and also to allow for cases where the Duration is used in a different way.

Additionally, the API requires passing a Duration, but the documentation says

Takes an integer value (seconds), this can bound the maximum number of attempts TCP will make to complete the connection.

In practice I believe that the special value 0 is equivalent to disabling the option and the duration is translated to a number of "retransmits" (capped at 255) so it may not be reliable. I don't believe that the current API is suitable, or if it is, it needs very heavy warnings.

[JohnTitor]

It's intentionally Duration, see #119639 (comment) and #140482

[asquared31415]

Another problem: the number of seconds passed also isn't a maximum either, it's a hint.

For example, if you pass 8 seconds to this API, that will get calculated as 4 retransmits, which will wait up to 15 seconds worth of retransmits. (as of linux kernel tag v6.18 (2025-11-30) which is what I have easily available at the moment)

This means that the duration can be significantly higher than the passed duration (up to 120 seconds longer in the most extreme cases I believe) or significantly lower (the duration is capped at 255 retransmits, which is about 29880 seconds or so if i'm doing the math correctly)