feat: support async_trait-less generation

[jrandolf]

Motivation

async_trait is not necessary for most use-cases. This PR provides the option for users.

Solution

Providing an option to generate async traits without async_trait.

Fixed: #1651

[jrandolf]

@LucioFranco Note that the current CI doesn't test all feature combinations. We should use cargo hack --feature-powerset test to ensure all features are covered.

[djc]

That's a lot of code duplication on top of what's already there. Given that the only difference is whether the method is prefixed with async or not and wrapping of the return type in impl std::future::Future<Output = ..>, can we simplify?

[jrandolf]

Decomposing a method to such an extent may not be advisable. It represents a premature optimization that could lead to developer confusion and complications. Understanding the interdependencies among the components within the decomposition requires extra caution, potentially increasing the risk of errors.

[djc]

That's not a satisfying answer to me. I don't think the term "premature optimization" applies here, since there's no performance impact to what I'm suggesting (indeed, the performance might well be worse).

I'm suggesting that the increased code duplication makes this code harder to maintain (for example, carefully reviewing these changes is a pain in the ass), and asking you whether that issue could be mitigated.

[jrandolf]

The changes have already been made. I was just expressing an opinion.

[jrandolf]

@djc Gentle ping. Could you please take a look?

[LucioFranco]

I think we need to generate the code as fn foo() -> impl Future + Send to allow sendable futures. We also need to check if the generated functions will work with the Arc since that also needs Sync. I would like to move in this direction but I don't feel like there is a huge rush. I would like to see some more tests as well checking all the permutations of sendiness/syncness so that we know this will work for users.