WIP: Add tokio async support

[hamidrezakp]

This PR will add support for tokio by adding two traits AsyncBorshDeserialize and AsyncBorshSerialize and their respective derive macros to be used in places that we have async reader and writer.

Feature gate = "tokio"

Here is works that needs to be done:

• Update documentation to address new trait and it's usage.
• Fix tests and write them for async pair of traits.
• Organize and rename new trait and modules to be more generic over async runtimes. (e.g. we may want to support async-std too)
• Disable feature gate as a default and make it optional

Anyway, here is the driver code for current working version:

use borsh::tokio::{AsyncBorshDeserialize, AsyncBorshSerialize};
use borsh_derive::{AsyncBorshDeserialize, AsyncBorshSerialize};

#[derive(AsyncBorshDeserialize, AsyncBorshSerialize, PartialEq, Debug)]
struct Custom {
    a: u8,
    b: Vec<String>,
}

#[tokio::main]
async fn main() -> std::io::Result<()> {
    let value = Custom {
        a: 12,
        b: vec!["Hello".to_string(), "From Tokio".to_string()],
    };

    let serialized = value.try_to_vec().await?;

    let expected = Custom::try_from_slice(&serialized).await?;

    assert_eq!(value, expected);

    Ok(())
}

Cargo.toml:

[dependencies]
async-trait = "0.1.68"
borsh = { path = "../../borsh-rs/borsh" }
borsh-derive = { path = "../../borsh-rs/borsh-derive" }
tokio = { version = "1.28", features = ["macros", "rt", "rt-multi-thread"] }

[frol]

This a massive! Thanks for the effort. It would be great if we can come up with some way to avoid code duplication as currently there seem to be 2 versions of code living side by side.

[frol]

Forgive my ignorance, but what is the point of using an async version of try_to_vec? It feels like a pointless method to me.

[hamidrezakp]

You are totally right!
we don't need that. i will remove it.

[hamidrezakp]

Thank you, yeah exactly, this is what i'm afraid of.

[frol]

It is going to be really hard to maintain and I fear that it will inevitably drift away, so I would keep it in PR for now to see if anyone will be able to come up with a better plan or maybe Rust async? syntax will mature.

[hamidrezakp]

It is going to be really hard to maintain and I fear that it will inevitably drift away, so I would keep it in PR for now to see if anyone will be able to come up with a better plan or maybe Rust async? syntax will mature.

Good idea,
I don't like the current plan tbh.