Hanson Char

Is this PR ready to be merged or do the 3 failing checks have to pass as a precondition?

Perhaps you can make a no op PR to see if it would pass all the tests, by making, say, only changes to some comments? That will help prove one...

Is this PR ready to be merged or do the 4 failing checks have to pass as a precondition?

Related (but orthogonal) to this great enhancement proposal, I see by default the TCP keepalive is disabled in `axum-server`, as TCP keepalive is disabled by default in `hyper`. This means...

Furthermore, currently the only configurable property for TCP keepalive in [axum_server](https://docs.rs/axum-server/latest/axum_server/struct.AddrIncomingConfig.html#method.tcp_keepalive) for incoming/accepted connections is the `Keepalive time` as defined at https://en.wikipedia.org/wiki/Keepalive. The other two properties,`Keepalive interval` and `Keepalive retry`...

Here is a PR for `hyper` to make all three TCP Keepalive parameters configurable: https://github.com/hyperium/hyper/pull/2991 If it was accepted, I would then post the corresponding PR to make this configurable...

Per empirical evidence enabling TCP keepalive with `intervals` and `retries` drastically/significantly improves the stability of persistent TCP connections while reducing the number of file descriptors via closing down dead connections.

I believe I've fixed all the stylistic issues reported by the workflow, but it doesn't seem I can trigger a re-run of the workflow. I also observed some workflow failures...

I see there are platform specific conditional compilations in the `socket2` crate causing some failure. Looking into them.

> Could just slap `#[cfg(unix)]` on the extra methods, and not worry about Windows... Right, but I am trying to make it such that the same API's can be provided...