@0x/utils: fix wrong RPC method in getChainIdAsync()

[feuGeneA]

It was using net_version, but it should be using the eth_chainId method introduced in EIP-695. I'm not sure whether/how the network ID differs from the chain ID on mainnet and the testnets, but in Ganache in particular, the network ID is 50 while the chain ID is 1337, and this difference was causing problems for Python tests. Specifically, the Web3.py interface Web3.eth.chainId invokes eth_chainId, and the result feeds into the order hash, which wasn't lining up with the non-Python side of things.

[dorothy-zbornak]

👀👍

[dekz]

We're passing in the chainId as a parameter to Exchange deployment. So this should've been passing in 50 inside the ganache snapshot. Exchange contract keeps this value around and it doesn't actually represent the executing chainId, rather the cached value at deployment time (as a parameter). So it's possible to deploy on mainnet with chainId 1337 even though this shouldn't be possible right?

Pedro's article on chainId versus networkId helps understand the real world difference between the two.

[coveralls]

Coverage remained the same at 75.286% when pulling a04da32 on fix/3.0/chainId-is-not-net-version into 59210f5 on 3.0.

[fabioberger]

Please don't bump the version here, this is done by Lerna at publish time.

[dekz]

Should we bump contract-addresses to use 1337 over 50 in this PR? Also all of the dependencies relying on lookup by networkId? https://github.com/0xProject/0x-monorepo/blob/development/packages/contract-wrappers/src/contract_wrappers.ts#L114