Like in #1460 the new web3 version we will get through the ethcontract
upgrade will have futures that must be run on tokio if the default http
transport is used.
In this case we cannot use services_core's http transport because we
would end up with circular dependencies. We could resolve that by
creating a new crate just for our custom http transport. Or we could
move the deploy binary into it's own subcrate so that it can depend on
contracts and services_core.
I don't mind doing that later but using tokio and keeping the the
default web3 http transport is easier initially.
Like in #1460 the new web3 version we will get through the ethcontract upgrade will have futures that must be run on tokio if the default http transport is used. In this case we cannot use services_core's http transport because we would end up with circular dependencies. We could resolve that by creating a new crate just for our custom http transport. Or we could move the deploy binary into it's own subcrate so that it can depend on contracts and services_core. I don't mind doing that later but using tokio and keeping the the default web3 http transport is easier initially.
Test Plan
CI runs the deploy script.