Add support for `autoRefreshOnNetworkChange` deprecation in Metamask

[SeanJCasey]

Metamask is getting rid of the ethereum.autoRefreshOnNetworkChange property, and suggesting that dApps rely on the ethereum.on("networkChange", callback) listener instead.

https://metamask.github.io/metamask-docs/API_Reference/Ethereum_Provider#ethereum.autorefreshonnetworkchange

Being able to force a dApp to reload on network change can be useful when there is logic that relies on the current networkId. In Drizzle, there is also the problem that web3 contracts that are added ad hoc with addContract would be instantiated with only the current network address, and would fail to function on network change.

[cds-amal]

Thanks for raising this @SeanJCasey.

Metamask is getting rid of the ethereum.autoRefreshOnNetworkChange property, and suggesting that dApps rely on the ethereum.on("networkChange", callback) listener instead.

https://metamask.github.io/metamask-docs/API_Reference/Ethereum_Provider#ethereum.autorefreshonnetworkchange

Yes, Drizzle will have to implement this listener.

Being able to force a dApp to reload on network change can be useful when there is logic that relies on the current networkId. In Drizzle, there is also the problem that web3 contracts that are added ad hoc with addContract would be instantiated with only the current network address, and would fail to function on network change.

These lines of code currently repair the contracts when a network change is detected. Though with the observable model Metamask proposes, we'll have to revisit.

[OnlyOneJMJQ]

Thinking through this it seems like we need a middleware modification to track network changes and update contracts accordingly.

We may also want to consider a unified source of truth around contract info that marries contracts passed in via drizzleOptions with the contracts added via addContract.