Implement GH-23879: Do not report an error on a zero accept timeout

[lazerg]

When stream_socket_accept() timed out with no client waiting, it went down the same path as a real failure and raised AcceptFailed ("Connection timed out"). That makes the usual "accept until empty" drain loop with a 0 timeout throw in StreamErrorMode::Exception, and the only way to tell a timeout apart from something like fd exhaustion was the message text.

The TCP and TLS transports now treat a poll timeout or EAGAIN as "nothing to accept" and return success without a client. stream_socket_accept() then returns false with no error for a 0 timeout, and reports TimeOut instead of AcceptFailed when a non-zero timeout expires. Real accept failures still report AcceptFailed. PHP_TIMEOUT_ERROR_VALUE moved from network.c to php_network.h so the transports can check for it.

Closes #23879

[bukka]

As I just noted in #23879, this is not a bug. So it should target master.

I'm also not sure why it does it only for non-blocking. It shouldn't really matter that much. Also there is a bit semantic change in php_stream_xport_accept() return value so that should probably be noted in UPGRADING.INTERNALS (so it couldn't probably target 8.6 in any case).

[lazerg]

I rebased onto master and dropped the non-blocking check in 5178927, so a timeout with no pending connection is now silent on blocking listeners too. The UPGRADING.INTERNALS note for php_stream_xport_accept() was already in the PR. I moved it to the 8.7 section and added an UPGRADING entry for the dropped error.

[bukka]

Hmm I think it should still produce error if it's not a 0 timeout. It might make sense to change that error to TimeOut . Only the 0 timeout would be ignored then.

[lazerg]

I changed it in 1cd4470. A 0 timeout with no pending connection is now silent. When a non-zero timeout expires, stream_socket_accept() reports TimeOut instead of AcceptFailed. The transports still return 0 with no client on a timeout, so stream_socket_accept() picks the code from the timeout it passed. The message text did not change.

[TimWolla]

As I just noted in #23879, this is not a bug. So it should target master.

As I replied there, I disagree on that and believe it makes a new feature pretty much unusable in practice.

---

It looks like this PR can resolve the issue without introducing any API / ABI change, making it theoretically applicable to PHP 8.6. I've requested PHP 8.6 RM review for them to decide.

[bukka]

I think we need to first agree whether it is a bug or feature. RM cannot decide this and we require full agreement on such topic. Currently we don't have such agreement - let's keep that discussion in the actual issue so we don't duplicate it here.

But even if we agreed that this this is a bug, there is, however, still semantic internal API change that this would introduce. It changes the php_stream_xport_accept() contract to return 0 with a NULL client and it currently changes the reported code for non zero timeouts