Support multiple instances of Web3 objects (for reasons of security/trust)

[cmditch]

See https://gist.github.com/frozeman/fbc7465d0b0e6c1c4c23#gistcomment-1741887 for impetus. I'm curious if this worry is still relevant, I suspect it is, despite services like Infura and MetaMask.

A number of ways to potentially go about this, but should not be priority, until user/dev demand necessitates it:

• Just have user utilize web3.setProvider in tricky ways (would likely break any events being watched)

• Create 'stateless' functions for one stop shop calls. Essentially create a TxParamsWithProvider for any function which takes TxParams.

• Remodel Web3.toTask and EventParams to take a Maybe Provider. Within Web3.js if Nothing then use default/current provider, if provider is set instantiate new Web3 for that call only. This would require creating a ton of Web3.Eth.funcWithProvider type functions, e.g., Web3.Eth.getBlock & Web3.Eth.getBlockWithProvider

• Use the effect manager to instantiate new Web3's and...?

[cmditch]

This has become relevant.

Relevant content from that link:

NOTE FOR DAPP DEVELOPERS!

From this version on Mist will not ship its own web3.js instance anymore. We only provide for now web3.currentProvider so you can connect to ethereum. In the future, we will provide a special ethereum object with a default provider.

Also this web3.currentProvider will not allow sync calls anymore, as it is already the case in MetaMask (and it's bad practice in general). So make sure to use the async ones e.g. web3.eth.accounts -> web3.eth.getAccounts(function(){...})

To instantiate your (self-included) web3.js lib you can use:

if(typeof web3 !== 'undefined')
    var web3 = new Web3(web3.currentProvider);
else
    web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));

[cmditch]

This would add too much complexity to the API, choosing to forgo implementation of this for the time being.