Fix race condition in network controller lookup() method.

[danjm]

This PR fixes a bug in the network controller that can be reproduced as follows:

• on the settings page, add a network that doesn't exist
• select ropsten (or any other infura supported network)
• select the custom network you just added and then immediately select ropsten again
• after a few seconds, infinite spinner will be shown and it will only be removable by switching networks and switching back

The bug is caused by something of a race condition in the network controller. When lookup() is called in controllers/network/network.js, as happens after a new network is selected, a net_version rpc call is made via ethQuery.sendAsync. If a custom rpc network which does not support the net_version is selected, the request for it will fail. The networkMiddleware created by createJsonRpcClient.js will be retried in eth-json-rpc-middleware/fetch 5 times, with a 1 second delay between each try. It will pass an error to the callback after the 5th try. ethQuery.sendAsync({ method: 'net_version' } in controllers/network/network.js handles that error by setting the network state to "loading".

If a network was successfully selected while those 5 retries were in process, the network state will incorrectly be set to 'loading', even though a network is loaded.

This PR corrects this by checking that the network state before the ethQuery.sendAsync({ method: 'net_version' } call is the same as right after the callback resolves. It does not update the network if it has changed while waiting for the callback to be called.

This is a relatively simple fix for the issue. Ideally, we would have a way of cancelling a net_version request that is already in process, but larger architectural changes will be needed.