This change fixes a bug in which specifying 0 for timeout-related options (such as the `timeout` option of `Addrinfo.getaddrinfo`) incorrectly results in an infinite wait.

(This change overwrites https://github.com/ruby/ruby/pull/15626 .)

[Bug #21506] Fix timeout in Addrinfo.getaddrinfo to actually take effect

This change fixes an issue where the timeout option in `Addrinfo.getaddrinfo` was not functioning as expected.

It also addresses a related issue where specifying `fast_fallback: false` with `resolv_timeout` for `Socket.tcp` and`TCPSocket.new` would have no effect.

The timeout option was originally introduced in:
https://github.com/ruby/ruby/commit/6382f5cc91ac9e36776bc854632d9a1237250da7

However, the value was noy used in current implementation:
https://github.com/ruby/ruby/blob/3f0e0d5c8bf9046aee7f262a3f9a7524d51aaf3e/ext/socket/raddrinfo.c#L1282-1308

Therefore, even if a timeout is specified and the duration elapses during name resolution, nothing happens. This is clearly not the intended behavior.

`Addrinfo.getaddrinfo` has been made interruptible as of Feature #19965.
This change uses that feature to interrupt name resolution when the specified timeout period elapses, raising a user-specified timeout error.
The timeout can be specified in milliseconds.

The same issue affects `Socket.tcp` and `TCPSocket.new` when `resolv_timeout` is set along with `fast_fallback: false`.
`resolv_timeout` was introduced in the following commits:
https://github.com/ruby/ruby/commit/6382f5cc91ac9e36776bc854632d9a1237250da7
https://github.com/ruby/ruby/commit/511fe23fa2bdf1f17faa91e0558be47b5bb62b2a

The reason is that with `fast_fallback: false`, these methods internally call the same `rsock_getaddrinfo()` as `Addrinfo.getaddrinfo`.
This change addresses that as well.

Since it's a singleton method, it should be referenced as `Socket.tcp_fast_fallback=`,
not `Socket#tcp_fast_fallback=`.

This change includes the following updates:
- Added an environment variable `RUBY_TCP_NO_FAST_FALLBACK` to control enabling/disabling fast_fallback
- Updated documentation and man pages
- Revised the implementation of Socket.tcp_fast_fallback= and Socket.tcp_fast_fallback, which previously performed dynamic name resolution of constants and variables. As a result, the following performance improvements were achieved:

(Case of 1000 executions of `TCPSocket.new` to the local host)

Rehearsal -----------------------------------------
before   0.031462   0.147946   0.179408 (  0.249279)
after    0.031164   0.146839   0.178003 (  0.346935)
-------------------------------- total: 0.178003sec

            user     system      total        real
before   0.027584   0.138712   0.166296 (  0.233356)
after    0.025953   0.127608   0.153561 (  0.237971)

Again, rsock_raise_socket_error is called only when getaddrinfo and getaddrname fail

According to the C99 specification section 7.20.3.2 paragraph 2:

> If ptr is a null pointer, no action occurs.

So we do not need to check that the pointer is a null pointer.

* Windows: Fix warning about undefined if_indextoname()

* Windows: Fix UNIXSocket on MINGW and make .pair more reliable

* Windows: Use nonblock=true for read tests with scheduler

* Windows: Move socket detection from File.socket? to File.stat

Add S_IFSOCK to Windows and interpret reparse points accordingly.
Enable tests that work now.

* Windows: Use wide-char functions to UNIXSocket

This fixes behaviour with non-ASCII characters.
It also fixes deletion of temporary UNIXSocket.pair files.

* Windows: Add UNIXSocket tests for specifics of Windows impl.

* Windows: fix VC build due to missing _snwprintf

Avoid usage of _snwprintf, since it fails linking ruby.dll like so:

  linking shared-library x64-vcruntime140-ruby320.dll
  x64-vcruntime140-ruby320.def : error LNK2001: unresolved external symbol snwprintf
  x64-vcruntime140-ruby320.def : error LNK2001: unresolved external symbol vsnwprintf_l

whereas linking miniruby.exe succeeds.

This patch uses snprintf on the UTF-8 string instead.

Also remove branch GetWindowsDirectoryW, since it doesn't work.

* Windows: Fix dangling symlink test failures

Co-authored-by: Lars Kanis <kanis@comcard.de>