Made the DataStore conditionally async

[phklive]

In this PR I propose the addition of conditional async for the DataStore trait:

This will enable the use of this trait in a web context ( WASM, WebGPU ) and is needed by the wallet team.

I have used the classic maybe-async-rs crate for multiple reasons:

• Our implementation of it in Winterfell: [winter-maybe-async] is mainly a copy paste of our needed functionality. But considering that we need to export it now to other crates outside of Winterfell like Miden base and Miden VM we will need more functionalities which would finally bring us to literally copy-paste the whole maybe-async-rs repo.
• We could pin the maybe-async-rs repo to a certain version to make sure that we do not have any dependency risk
• maybe-async-rs provides useful macros for testing and for conditional compilation of code in sync and async context
• maybe-async-rs is async first when our implementation is sync first which prevents the use of tokio which requires main functions to be async in downstream crates.

Still a WIP, making some tests.

closes: #668

[phklive]

@bobbinth I have a few questions regarding:

• Testing: for now all tests have been kept as they were, hence annotated to only run in sync, should we add async tests ? Should we modify the existing tests to also be able to run in async mode and potentially have a CI job to test sync and test async ?
• CI and Makefile: Would you want to add additional targets regarding sync / async ?

[bobbinth]

Thank you! But as I wrote on discord, I think we should go with a different approach. Specifically, we should use winter-maybe-async and modify it as needed for our needs. The reasoning is as follows:

• It doesn't make sense to use maybe-async-rs in one place and winter-maybe-async in another. We should use the same crate everywhere.
• The code should be sync by default and enable async via a feature.
• maybe_async-rs is not popular enough in my opinion to use it as a core dependency.
• We should try to move away from using async_trait in favor of native Rust functionality (cc @igamigo to see if this will cause issues for the client).

So, we should either update the current macro implementation in Winterfell to work for the use cases we need, or split it into maybe_async and maybe_await macros as discussed previously.

[bobbinth]

• Testing: for now all tests have been kept as they were, hence annotated to only run in sync, should we add async tests ? Should we modify the existing tests to also be able to run in async mode and potentially have a CI job to test sync and test async ?

Would be good to add one or two async tests, but these can be done in another PR.

CI and Makefile: Would you want to add additional targets regarding sync / async ?

Once we have separate async tests, we should update CI/makefile to run them.

[bobbinth]

Closing this in favor of #725.