decide what to do with tower

[GlenDC]

That rama is to be built in the "tower" spirit is clear. However at the moment we make use of https://github.com/plabayo/tower-async rather then the original https://github.com/tower-rs/tower. Reason being that only with a lot of boxing one can make use of async functions within a Tower Service.

For now tower-async fulfils that needs. However:

• it requires the use of a nightly feature to be able to use call(): Send: tracked in Tracking Issue for return type notation rust-lang/rust#109417. It's not even certain that RTN will make it;
• Dynamic dispatch does not yet work (https://rust-lang.github.io/async-fundamentals-initiative/explainer/user_guide_future.html#dynamic-dispatch-and-async-functions) for async fn traits and this is for a long time to come;

On top of that it means we have to put in the work to maintain an entire alternative tower ecosystem ourselves.

tower-rs/tower#753 was opened to help decide that.

So far it seems that the impl_trait_in_assoc_type usage would be the way to go and would allow us to make use of tower as-is, and refer to futures. Where we need async opaque types we can make use of type Future = impl Future<...>. However what is less clear is if they also want to go for &self instead of &mut selfand whether they want to get rid ofpoll_ready` in the default contract. Which would still be desired.

Tracking issue for assoc type: rust-lang/rust#63063

As there is a lot of unclarity here, and as tower-async does work just fine for now and we already spent a lot of time on it, for now we can just keep it as-is. Once there is more clarity in regards to the direction of tower, and once we have time for it, we can look back it it. Anyone who wishes can also provide feedback here in regards to tower usage within rama and the direction we might want to take.

[GlenDC]

After consideration, taking into account feedback in tower-rs/tower#753 as well as reading through https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html and linked resources, it seems clear that the async story is not yet ready for tower+tokio like systems. On top of that we clearly run into:

• time issues as maitaining this entirely on my own takes a lot of time;
• it also takes time away from actually being able to contribute to tower itself;
• limitations, where stuff like boxing for rama purposes cannot be supported unless we make the entire tower-async Send enforced... (see reintroduce boxed service tower-async#12)

So instead... I think, we'll cut our losses, consider what we learned from it... and,.... move back to tower itself.
This does mean we might need to box for now, but it does also mean we can at least move back to Rust stable, and have less work in it.

On top of that I start to doubt that it really makes sense to try to wrap everything. For the runtime it does make sense, but for tower I do think it's a bit much... Instead I start to like more and more the way Axum handles it.

Lastly, if we go for regular tower services it will also play a lot nicer with hyper as-is.

It is also probable that the combination of being able to run on rust stable + using the regular tower ecosystem, would allow others to adopt rama a lot easier.