Allow withholding the SYN|ACK packet by user code

[cvengler]

We at The Tor Project, Inc. have been using this trivial patch in a downstream fork of smoltcp for almost 1.5 years. We never bothered to upstream it, because the assumed the feature was too much of a niche one. However, given the recent release of oniux, which uses the downstream fork of smoltcp extensively, we thought it is a good idea to upstream it, given that many distributions already bundle oniux themselves.

---

In certain use cases, it's desirable to not send a SYN|ACK packet immediately after receiving a SYN -- for example, a TCP proxy that doesn't want to do so until it's connected to the end destination, because the outgoing connection might get refused. (Currently, you have to send a SYN|ACK and then reset the connection afterwards in this case.)

To fix this, add a simple synack_paused flag, controllable by user code, that withholds SYN|ACK packets in SynReceived state until it is unset.

[cvengler]

I assume the CI failures are related to outdated versions in the main branch? This PR is at least not modifying any parts of Cargo.toml et, al.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.17%. Comparing base (e2b75e3) to head (e02fced).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1063   +/-   ##
=======================================
  Coverage   81.17%   81.17%           
=======================================
  Files          81       81           
  Lines       28955    28958    +3     
=======================================
+ Hits        23503    23506    +3     
  Misses       5452     5452           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cvengler]

My bad, there was already a PR for it in #863.

I do understand the argument made there but given that this is more or less already deployed in production systems I think it is worth iterating over it again.

[whitequark]

@Dirbaio How about adding this feature behind a feature flag?

[Dirbaio]

Yes, I'd prefer it to be gated behind a cargo feature so it doesn't increase code size when you don't need it (yes it's very little code size but for embedded use cases i'll take every byte I can get 😅 )

Also, could you add a test?

[cvengler]

Sure thing!
Do you have suggestions for a name of that feature flag?
I would just go with pause_synack?

[Dirbaio]

probably socket-tcp-pause-synack for consistency with the other flags that enable tcp features.

[cvengler]

placed it behind a feature flag and added a unit test 🙂