feat(http server): add new builder APIs build_from_tcp and build_from_hyper

[niklasad1]

Before the HTTP server configured the socket explictly but this PR changes to use tokio::net::TcpListener similar to what the WsServer does

In addition this PR adds another API for users to provide their own TcpListener, see the inline example I added with socket2.

Example:

   /// use jsonrpsee_http_server::HttpServerBuilder;
   /// use socket2::{Domain, Socket, Type};
   ///
   /// #[tokio::main]
   /// async fn main() {
   ///   let addr = "127.0.0.1:0".parse().unwrap();
   ///   let domain = Domain::for_address(addr);
   ///   let socket = Socket::new(domain, Type::STREAM, None).unwrap();
   ///   socket.set_nodelay(true).unwrap();
   ///   socket.set_reuse_address(true).unwrap();
   ///   socket.set_nonblocking(true).unwrap();
   ///   socket.set_keepalive(true).unwrap();
   ///
   ///   let address = addr.into();
   ///   socket.bind(&address).unwrap();
   ///
   ///   socket.listen(4096).unwrap();
   ///
   ///   let server = HttpServerBuilder::new().build_from_tcp(socket).await.unwrap();
   /// }
   /// ```

[jsdw]

Ooh offhand this looks very neat, I like it! I also like that it removes socket2 as a dependency and leaves it to the user to provide their own socket thing (if I read it right)!

[niklasad1]

yeah, you are right and that is the idea :)

AFAIK, most socket libraries implements Into<StdTcpListener> and hyper has a similar API

[jsdw]

Loooks good to me; I really like letting somebody provide (and configure) their own socket rather than handling it internally :)

[niklasad1]

@jsdw is this API reasonable?

Basically the only thing I want to ensure is that no settings gets overwritten without informing the users of this API.

It's a bit awkward to configure some settings twice but no way around that....

[jsdw]

Aah ok, so the issue is now basically that you can pass in a TcpListener, but you can't configure the Hyper server that is created from it.

One option might be to keep build_from_tcp() as is (which lets you pass in a pre-configured tcp listener but assumes you don't care about how the resulting hyper server is configured), and also have a build_from_hyper() as well (which lets you control everything about the tcp listener and hyper server if you wish). So then you'd have:

• build -> can't configure socket, can't configure hyper.
• build_from_tcp -> can configure tcp socket, can't configure hyper.
• build_from_hyper -> can configure tcp, can configure hyper.

What do you reckon?

[niklasad1]

fair enough, I think your suggestion is less awkward.