Multi threaded support for Orchestrator via tokio runtime instead of actix_rt

[rnbguy]

Surfaced from @informalsystems audit of Althea Gravity Bridge at commit 19a4cfe

severity: Informational
type: Restructuring proposal
difficulty: Easy

Involved artifacts

• Orchestrator

Description

Switch to Tokio multi threaded runtime

Actix RT uses tokio based single thread runtime.

We believe the actix_rt dependency comes from web30 (Althea is the maintainer) which has a dependency to awc.

We would recommend moving awc to hyper+tungstenite and actix_rt to tokio runtime ({ features = ["macros", "rt-multi-thread"] } on Cargo.toml) for multi threaded support.
This will enable multi threaded performance improvements. But make sure, everything is thread-safe. This will probably need no intervention(impl Send). But even if it does, Rust compiler can provide necessary guidance.

For that to work, it will be necessary to replace actix_rt::main with tokio::main at orchestrator/gbt/src/main.rs#L29.

Enable parallelization at many loops

It is possible to enable parallelization at many loops using rayon::iter::ParallelIterator or futures::stream::StreamExt::for_each_concurrent.
One can use rayon or futures::streams to do this depending on non-async or async usage respectively.

Consider e.g the example from orchestrator/relayer/src/batch_relaying.rs#L197:

• Since it is a loop over HashMap, the order doesn't seem to be important.
• Also the token batches should be independent of each other.

This can be parallelized by futures::stream::StreamExt::for_each_concurrent or futures::stream::StreamExt::try_for_each_concurrent on Async multi threaded runtime.