Fix GH-19248: Use strerror_r instead of strerror in main

[bukka]

This tries to use strerror_r in networking and stream code. It required some extending of php_socket_strerror and php_socket_error_str which is not exactly beautiful but can't think about much nicer way atm.

[bukka]

It will need more testing. Need to figure out how to actually test the posix variant to make sure that it all works. Also need to figure out if we even have all those errors covered so there is still a bit of work.

[bukka]

Ok so XSI variant (returning int) is used on FreeBSD and MacOS which is tested and showed an issue. I just fixed that.

Another thing is Windows. The fact that I replaced strerror with php_socket_strerror in some places means that Windows will now use php_win32_error_to_msg that uses FormatMessageW and results in a more explaining error. The side effect is that it breaks many tests because those are Windows specific messages but maybe it's not really a problem. But not sure if it's ok for stable version. Alternatively I could introduce a special variant for Windows using strerror_s . @cmb69 What do you think about this?

[cmb69]

I'm afraid that switching to php_win32_error_to_msg() is too much of a BC break – some code might actually "parse" the error messages, and there might be some tests relying on the messages. And IIRC, php_win32_error_to_msg() produces localized error messages, what might be even worse. So I think it would be better to go with strerror_s() for now, and only switch to php_win32_error_to_msg() for master.

[bukka]

Ok I introduced a special php_socket_strerror_s variant that is used for the cases that were using strerror directly. This has special implementation on Windows to use strerror_s and for other platforms it is just a macro for php_socket_strerror. CI is green so hopefully all good.