feat(server): allow custom implementations of listener

[joelwurtz]

Ref #1190

See this comment : #1190 (comment)

This allow end user to create its own listener as long as it returns a xitca_io::net::stream

I did not make stream generic (could be in the future) neither.

Compared to the comment i choose to not make the Listen type generic, it could be in the future with another PR

In draft for the moment as i want to test this change on my project to be sure that i achieve what i want (getting back listener after shutdown)

[joelwurtz]

Passing this as ready for review, i can confirm that this is enough for a first implementation of having its custom listener.

With this i'm able to retain listener after server stop and forward them to another process

#1218 is also required to do that on quic socket

[fakeshadow]

I don't think we need both Listen and ListenDyn here. As there is no additional abstraction on top of the trait for zero cost async trait methods. Remove Listen and rename listenDyn would be sufficient.

Also Arc<Box<dyn Listen>> is double indirection and we can just use Arc<dyn Listen> instead. This would reduce some memory overhead.

Also if dyn Listen is gonna be used anyway we can remove Listener enum and implement the trait on all it's variants types directly.

[joelwurtz]

If we keep only ListenDyn instead of both it means that we will have to write something like this :

impl Listen for Listener {
    fn accept(&self) -> Pin<Box<dyn Future<Output = io::Result<Stream>> + Send + '_>> {
        Box::pin(async move {

instead of

impl Listen for Listener {
    async fn accept(&self) -> io::Result<Stream> {

Or maybe i'm missing something ? (just find it clearer and consistent to be able to write async trait directly like other trait in xitca)

Will add the changes about Arc and listeners

[fakeshadow]

The main problem here is we don't want to expose these types to users and cause possible confusion. Take ListenObj for example it may make users wonder what ListenDyn is or even what Arc. That said it also make sense as stuff like Pin/Box/Future can also be source of confusion. So there is maybe other alternatives we can look into.

I imagine we can do the following to hide ListenDyn trait from user and keep the public traits and types to minimal:

pub trait IntoListener {
    // add an associate type for listener
    type Listener: Listen

    fn into_lisenter(self) -> io::Result<Self::Listener>;
}

pub trait Listen: Send + Sync {
 ...
}

// hide ListenDyn trait from public
#[doc(hidden)]
pub trait ListenDyn {
    ...
}

type ListenerFn = Box<dyn FnOnce() -> io::Result<Arc<dyn ListenerDyn>> + Send>;

// cast listener object inside crate so neither Arc nor ListenDyn is visiable from public api
Box::new(|| listener.into_listener().map(Arc::new))

[joelwurtz]

Should be better with last commit then

[fakeshadow]

I believe we can remove the Listen impl for Box<impl ListenDyn> as we only use ListenDyn internally. Otherwise its good.

[joelwurtz]

Done

[fakeshadow]

Thanks the PR is good. I'll resolve the CI issue separately.