Verify that tokio 0.2 fixes concurrency bottleneck

[lukesteensen]

Our assumption has been that tokio 0.2, with a completely rebuilt scheduler, should no longer suffer from the issue we were seeing at high concurrency levels (see #391). We should verify this assumption and remove our hardcoded concurrency limit if that is true.

This should follow #1695, and we can use pretty much the same plan of attack. The first step should be to remove the current thread limit on a branch. We can then try to reproduce the original issue of plummeting throughput at higher thread counts on the current runtime and see whether or not it still occurs on the 0.2 runtime.

[Hoverbear]

Seems related to #1922 ?

[MOZGIII]

It's related. It depends on whether we'll do this assertion at part of #1922, or if we'll do it separately. Technically, it's not a blocker for #1922, and can be addressed separately. If we do validate this as part of #1922, I'll close this.

[MOZGIII]

This was not validated, so reopening it.
Any suggestions on how to approach it?

[binarylogic]

Yep, a test on the test harness with a high cpu instance should do it.