Bump to Libuv 1.52.0

[truemedian]

https://github.com/libuv/libuv/releases/tag/v1.52.0

• Adds udp_open_ex, which allows passing reuseaddr and reuseport options to uv_udp_open.
• Adds tcp_keepalive_ex, which allows passing KEEPINTVL and KEEPCNT options to uv_tcp_keepalive.
• Adds the frsize field to the statfs table, which contains the fragment size of the filesystem.
• Adds the UDP_REUSEPORT constant to the constant table.

The existing suite has no tests for udp_open, so I have not added any for udp_open_ex. Given that uv_udp_open just calls uv_udp_open_ex with default options, this change shouldn't cause any regressions.

[squeek502]

All the previous _ex functions are a bit different in that luv doesn't provide 1:1 bindings for them (uv_udp_init_ex is within luv_new_udp, uv_tcp_init_ex is within luv_new_tcp, and uv_thread_create_ex is within luv_new_thread), but the precedent for those has been to adapt the current API to use the _ex functions in a backwards compatible way (i.e. no new function introduced, just switch to calling _ex within the implementation when appropriate).

It seems like that approach would work for these new _ex functions, too, so curious to hear your thoughts on that.

[zhaozg]

I think the the _ex as an extension of normal interface, for example, it adds support for more flags.

On the Lua side, it is better to keep a single interface. This way, it preserves the new extension capabilities without increasing complexity for Lua calls. Binding it 1:1 directly to the C API and Lua API is not the usual practice in Lua.

[truemedian]

My thought process was to ensure that the user could expect the semantics of any flags that they pass to luv (ie. if you pass reuseport, then you can expect that the handle has those semantics; or libuv throws EINVAL because the system doesn't support it), but I see now that the other cases of _ex functions instead just drop whatever flags the function doesn't support.

Will go ahead and draft up a fix to merge both functions back into their non _ex form.