Switch to tokio, and update dependencies

[Vrtgs]

implement the #588 suggestion

[bee-san]

Thank you so much for this! We take performance seriously here. I'll have to read up more on Tokio vs STD:ASYNC but I think you're right, Tokio in my opinion would be faster now-a-days :)

[Vrtgs]

opps forgot to make a new branch, sorry for the extra pushes

[bergabman]

I'd like to add some things regarding the arguments in issue #588. It's the PR related to it, and I figured we could keep the discussion in one place.
First some context; Back in the day of creating rustscan the situation was slightly different. Tokio had a different api, structure, that was inconsistent with the rust ecosystem, and async-std promised a way more consistent, rust std feel for their async implementation. However this has all changed when async await got stabilized and tokio got completely rewritten. Looking at how async-std got no update in the past 2 years, it makes a whole lot more sense now to switch to tokio, so I agree on that point.

Considering performance, the scan engine was built on top of FuturesUnordered, which is a more generic futures implementation and not part of async-std, it's part of the futures crate. The reason for this decision was performance, and to not rely on async-std in performance critical parts of RustScan. As async await was just stabilized back then, we knew things would change, supporting the decision to stick with FuturesUnordered.
As @bee-san stated, performance is critical. I noticed that you replaced FuturesUnordered with JoinSet from tokio in the scan engine. L81 Based on some discussions in the tokio repo tokio-rs/tokio#5564, this decision would set us back with 5-18% in performance in general, because of a design decision in the implementation of JoinSet.
I haven't done a performance comparison myself, but it would be benficial to see if there is actually a performance difference between the 2 implementations in our case. Based on the benchmarks, and the discussion in that issue, I would prefer to stay with FuturesUnordered, but if the benchmark shows different, we can go with JoinSet, completely remove the futures dependency and use tokio everywhere.