Feature-gate `async_trait` in lieu of new, standardized `async_fn_in_trait` feature.

[Qix-]

Would it be possible to put the async-trait stuff behind a feature of the same name, and then use a #[cfg_attr(feature = "async-trait", ::async_trait::async_trait)] for all occurrences, such that we can use the newly stabilized async-in-trait functionality?

[Sherlock-Holo]

for now trait-variant can't handle default methods, but I think if it support, russh can use AFIT directly instead of the async-trait crate

[Eugeny]

Sadly this doesn't work yet as native async trait futures aren't Send and can't be used to spawn tokio tasks: https://blog.rust-lang.org/inside-rust/2022/11/17/async-fn-in-trait-nightly.html#limitation-spawning-from-generics

[indietyp]

That isn't completely true, if you specify the desurgared form in a trait definition you can specify additional bounds (like Send + 'static) in implementations you can still use async fn.

You can see this in action here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ec570d1da8499bb14e80bac0827e233b

Comment out the Rc implementation to see a compilation error. (with RPITIT normal future rules apply, here just using Rc to illustrate the point more clearly)

[Eugeny]

Thanks for the tip! I gave it a try and unfortunately I'm running into rust-lang/rust#110338

If you want to give it a try: #244

[Qix-]

As a complete alternative (a large, hairy alternative), it might be a good evolution to implement proper Future types, given that russh is a library. Then all of these issues go away. But that's a massive change, for sure.

[qsantos]

I took a look at #244. Removing entirely async_trait and the explicit lifetime annotations seems to work (well, except in russh/examples/sftp_server.rs since that would require updating russh_sftp as well).

I understand that removing async_trait is a breaking change, but Axum just ripped off the band-aid, and we might want to do that earlier rather than later if it has to happen at some point. Do you think that would be too disruptive?