refactor: Remove `async_trait` in `Catalog` trait.

[liurenjie1024]

After #140 get merged, we will be able to use async fn in trait, and async_trait macro is no longer needed.

[hiirrxnn]

Could I work on this ? Please tell me what precisely is to be done here?

[liurenjie1024]

Could I work on this ? Please tell me what precisely is to be done here?

The release of rust 1.75 enables a fancy feature so that we no longer need to use async_trait macro, you can read this blog for reference.

You can also see the FileWriter trait in this pr as an example.

[jdockerty]

Is there any movement on this one? I see there was a prior PR to close, but it was closed pending upstream releases.

If there's nobody working on it anymore, I would like to take a shot at it if that's okay 👍

For mine/anyone else's reference, is there a preference to using impl Future<Output = ...> or maintaining the async fn signatures with trait_variant crate?

[liurenjie1024]

Is there any movement on this one? I see there was a prior PR to close, but it was closed pending upstream releases.

If there's nobody working on it anymore, I would like to take a shot at it if that's okay 👍

For mine/anyone else's reference, is there a preference to using impl Future<Output = ...> or maintaining the async fn signatures with trait_variant crate?

Hi, @jdockerty Thanks for you interest, I think we can go on this work after rust-lang/impl-trait-utils#27 is release on new rust release.

[Xuanwo]

I personally do not favor adopting async in trait for the Catalog API because it compromises object safety. Users will no longer be able to use Box<dyn Catalog>. All APIs related to Catalog should include generic parameters.

[Xuanwo]

I propose closing this issue as it's unlikely we'll remove async_trait from Catalog until easier methods for implementing object-safe trait objects are available. Additionally, catalog API calls are usually not on the critical path in most of our use cases. Adding such a maintenance burden isn't worth it.

cc @liurenjie1024 @jdockerty

[liurenjie1024]

+1, we can close this first.