Control caching behavior of contract_type and proxy_info on live networks [APE-911]

[BowTiedDevil]

Overview

When fetching contract data from a block explorer on a live network, the results are cached in .ape/{ecosystem_name}/{network_name}/contract_types/{address}.json, which is very helpful if you intend to use the contract object again.

However for contracts instantiated with a limited ABI (a minimal ERC-20, for example), the cache remains and must be manually removed and re-fetched to restore full ABI functionality, or to clear storage space.

Specification

An existing JSON file may be passed as the contract_type using Contract(address,contract_type=ContractType.parse_file(path)) where ContractType is imported from ethpm_types

The caching behavior could be controlled with an optional argument cache that defaults to True so existing scripts behave as expected.

Example call that would disable caching to storage: Contract(address=POOL_ADDRESS, contract_type=ContractType.parse_file(FILE_PATH), cache=False)

Dependencies

None

fixes: APE-911

[BowTiedDevil]

I will redo the PR after reviewing CONTRIBUTING.md and reformatting

[fubuloubu]

contract_type already overrides whatever the cache has (I believe), so we can add a kwarg ignore_cache or update_cache (boolean defaulted to False) that can be set true to force re-downloading the type via explorer. I think this will improve the UX around purging the cache value in cases where it's not set correctly

Alternatively, there could be some algorithm that merges what's in the cache with whatever the explorer provides (if available), or whatever a user provides via contract_type input. This could be used to solve some of the issues with proxies where the proxy has additional methods from the implementation contract (such as upgradeable proxies)

[BowTiedDevil]

I had not considered the case of a forced update, I will work on this and wrap into the next PR.

[fubuloubu]

I had not considered the case of a forced update, I will work on this and wrap into the next PR.

Thanks for taking this on!