Add keepalive, set_keepalive to TcpStream implementations

[yungcomputerchair]

What

The current implementation of TcpStream does not expose SO_KEEPALIVE: #69774

Why

It seems the reason this has not yet been implemented is because the initial implementation went as far as to take the keepalive interval as a parameter. However, Windows does not directly expose these intervals for reading, causing there to be some debate about the shape of the API (see the discussion of this here).

How

I am proposing that this API is enabled with a bool parameter to align with the implementation in both Windows and Unix, as it is the least common denominator between the two of them. With regards to the call to setsockopt, Windows expects a disable/enable, and Unix does as well.

The extra configuration for Unix that allows the interval to be tweaked could be done through an additional API perhaps, but I don't think that's stopping us from exposing the switch to at least enable the behavior with the OS defaults.

[rustbot]

r? @joboet

rustbot has assigned @joboet.
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, joboet

[yungcomputerchair]

As a new contributor, there were a few things I wasn't sure about:

• I don't think there is a "tracking issue" for this feature, just the one I linked above with the discussion. I am guessing a tracking issue will need to be created for this, and the issue number in the code will need to be updated.
• I don't know if unstable features are defined somewhere, so I just made sure the name was unique and matched for both new APIs.
• For motor, the lib does not expose a keepalive setting (according to the docs), so I went with unsupported()
• For SOLID and Hermit, I believe the implementation was straightforward, but I'm not sure how to test. Is there a CI flow I can use?
• Is there anything else I need to do to validate or properly propose this change?

Thanks :)

[joboet]

• Is there anything else I need to do to validate or properly propose this change?

You'll need to put forward an API change proposal.

• I don't think there is a "tracking issue" for this feature, just the one I linked above with the discussion. I am guessing a tracking issue will need to be created for this, and the issue number in the code will need to be updated.

You can create one after the ACP is accepted.

• I don't know if unstable features are defined somewhere, so I just made sure the name was unique and matched for both new APIs.

Yup, that's all that's necessary for library features.

• For motor, the lib does not expose a keepalive setting (according to the docs), so I went with unsupported()

Yeah, that should be fine.

• For SOLID and Hermit, I believe the implementation was straightforward, but I'm not sure how to test. Is there a CI flow I can use?

These platforms don't support running the test suites, so unfortunately no. These are tier 3 though, so it's fine if things don't work out – the target maintainers are responsible for keeping things working. It's always a good idea (and very polite) to run

./x check library/std --target x86_64-unknown-hermit

(or aarch64-kmc-solid_asp3 for SOLID) though, to rule out any trivial mistakes.

[yungcomputerchair]

Thanks for the quick and concise responses! I'll check those tier 3s and fill out an ACP.

[yungcomputerchair]

I have filed an ACP: rust-lang/libs-team#762
I also had to back out the implementation on SOLID, as the option seems to be unimplemented there. The implementation for Hermit checked out, though.

[yungcomputerchair]

My ACP has been approved; let me know if there are any other steps left for me to take.