Default to async-std

[sveitser]

There's no issue, based on discussion on zulip it should not be required for consumers of this crate to always set RUSTFLAGS.

Instead of checking for presence of async-std, tokio or flume specified with --cfg the crate now checks for presence of tokio or flume and defaults to async-std if neither of those are set.

This PR:

• Change cfg directives to use async-std channels and executor if
  nothing is specified via rust flags.
• Add new empty RUSTFLAGS matrix variant to CI jobs.
• Add a justfile for local testing.
• Update README.
• Fix and simplify flake.nix.

This PR does not:

• Fix all the outdated comments, for example about cargo features.

Key places to review:

The cfg directives.

How to test this PR:

For example with just test-all or the other added just recipes.

Things tested

Manually tested that setting setting channels to tokio without using the tokio executor still fails. E. .g. env RUSTFLAGS="--cfg async_channel_impl=\"tokio\"" cargo check

[sveitser]

I'm not sure why these were all and if that was intentional.

[rob-maron]

Not sure on the Nix stuff, but it looks good to me.
One thing to look for when integrating upstream is we will have to change the flags there as well. Some repositories have cfg_attrs that map to tokio::main and async_std::main

[sveitser]

I just made the more or less simplest nix flake that has everything this project needs. I tested it on NixOS and OSX. I didn't say anything because I thought it runs in the CI anyway and will be tested there but that workflow doesn't trigger on PRs.

Triggered it manually now: https://github.com/EspressoSystems/async-compatibility-layer/actions/runs/9028630166/job/24809455559

It does still fail (like on main) so I will fix that.

[sveitser]

Fixed now: https://github.com/EspressoSystems/async-compatibility-layer/actions/runs/9028721591

[sveitser]

Not sure on the Nix stuff, but it looks good to me. One thing to look for when integrating upstream is we will have to change the flags there as well. Some repositories have cfg_attrs that map to tokio::main and async_std::main

I think we should use async_main from this crate instead.

async-compatibility-layer/src/art/tokio.rs

Line 4 in ccf2d44

main as async_main,

async-compatibility-layer/src/art/async-std.rs

Line 4 in ccf2d44

main as async_main,

Although this doesn't seem to play nicely with rust-analyzer. If I write async_main it suggests me to import async_std::main 😒

[sveitser]

For tokio::main hotshot sometimes passes flavor = "multi_thread" and sometimes uses the default but multi_thread is the default according to https://docs.rs/tokio-macros/latest/tokio_macros/attr.main.html#multi-threaded-runtime, so I think this can be switched to async_main.

For tokio::test hotshot always use flavor multi_thread but sometimes customizes worker threads, setting it to 10 or 2.

[sveitser]

@jbearer Do you have any thoughts on this matter? It seems that currently this crate does not provide all the features needed for compat between async-std and tokio in hotshot because in hotshot sometimes arguments are passed to tokio::test. Should we add functionality to async_test so that the user can pass arguments to tokio::test?