inet: {send_timeout_close, true} leaves hanging port and doesn't send tcp_closed to owner

[v0idpwn]

Describe the bug
Disclaimer: I'm not 100% sure this is a bug. I can see it being intended behaviour, but I found this very unexpected, I think at least a documentation improvement could be made, or this issue could be of reference for other people facing the same problem.

Upon a send timeout on a gen_tcp socket using the inet backend and {send_timeout_close, true}, the underlying FD is closed, but the port stays open, erroring on future calls. Owners in active mode don't get any notification, even if the sender is not the owner.

I found out about this behaviour with zombie ports in my application, where a gen_tcp:send result was ignored, and a timeout on it would cause {active, N} workers to wait a long time for nothing.

The new socket backend doesn't have this issue, everything is closed on send timeouts, and the owner gets notified about the close.

To Reproduce
Have a process own an inet socket, {active, true}. Have a second process trigger the close timeout. I attached a script reproducing it.

Expected behavior
tcp_closed message to arrive in active owner mailbox. Potentially port being closed (?)

Affected versions
Tested OTP 27 and OTP 29.

Additional context
Reproducer

[RaimoNiskanen]

We will/are look/looking in to this. The owner, in active mode, should be notified when the socket is closed, and when the socket is closed, the port should be closed. At least per default. There is an option exit_on_close that can be set to false to avoid that, which could maybe be valid to honour here too.

The current behaviour is not intentional.