Support extended keepalive parameters in epoll and io_uring

[ivu-mawi]

EpollTransport: support extended keepalive parameters TCP_KEEPIDLE, TCP_KEEPCNT and TCP_KEEPINTVL

Builds on #5183. This work has not made it into master, so I'm catching up on that.

I hope I've ported it correctly given the refactoring of the TCPSSLOptions / TCPConfig.

For motivation, see #5163 and #5183 and #5970

[vietj]

I am wondering for the new config to potentially have an Option object to be more extensible than what we have now.

[vietj]

@ivu-mawi I have introduced generic TCP option, can you rebase on master

[vietj]

that only affects the new config

[ivu-mawi]

Seems good! I'll gladly rebase when I get the chance, which will be next week only I'm afraid.

[tsegismont]

No problem @ivu-mawi . Thank you!

[vietj]

why is that PR still in draft mode ?

[ivu-mawi]

I'm trying to verify locally that it actually works. But I can't seem to get packet capturing to work in WSL (Windows subsystem for linux), and that's the only Linux I have access to at the moment. :(

I'll give up the test. Code is ready, I'll mark it ready.

[vietj]

@ivu-mawi an you rebase on latest branch to resolve the git conflict ?

[ivu-mawi]

Fixed unit tests by disallowing 0 as value again

[ivu-mawi]

One thing I'm not sure about with the new TcpOption is we're setting various parameters to -1 explicitly now, even though the intention in some of the code seems to have been that -1 means "don't set the option on the actual socket, leave whatever the OS default is". I couldn't find any docs as to whether setting these options to -1 explicitly is allowed or breaks something.

[ivu-mawi]

Oh, it looks like exactly that is actually causing an error in the pipeline runs.

[ivu-mawi]

We can see here that Linux does not allow any value < 1.

I have made it so that 0 instead of -1 is now the special value that means "do not set, leave OS-default". This is technically incompatible to the code from vert.x 4.x, but I'd say that's okay. Probably very few people will explicitly use -1, and if they do, they will get a runtime exception after upgrading to vert.x 5, and have to change it to 0.

I've done that just because it's nicer to have a isNullOrZero method than a isNullOrMinusOne method ...