Fix initialization of Contract function and events

[fselmo]

Closes #3553

What was wrong?

• When we init contracts, we currently have an overhead of initializing 3 ENS contracts per contract instance. If a user doesn't use the ENS contracts, this ends up being very unnecessary overhead. Instead of instantiating the ENS contracts at every contract init (w3.ens), set all initializing vars to w3._ens which is the reference that w3.ens looks for. This leaves the check for an empty w3._ens followed by subsequent instantiation for when w3.ens is called directly by the user, not for any internal setup.
• We are needlessly re-creating contract functions both for the Contract init, as well as for the ContractCaller. The caller is instantiated in the Contract init when we set self.caller = ContractCaller(...). Pass along the already built ContractFunctions to the ContractCaller so that it doesn't have to re-build them.

How was it fixed?

• Use reference to w3._ens rather than w3.ens (which initializes an ENS instance if it is empty).
• Allow passing contract_functions: ContractFunctions to the ContractCaller class so that we can pass the functions around instead of rebuilding them everywhere they are needed.

Todo:

• Clean up commit history
• Add entry to the release notes

Cute Animal Picture

[reedsa]

@fselmo couldnt add you as a reviewer of your own PR, but I've got all changes pushed up. I appreciate your feedback!

[kclowes]

I didn't do a terribly deep dive here, but this looks good on a high level! I left a couple nits, but the biggest things I'm wondering about are:

• what does the benchmarking say here; does this make a meaningful impact? (I assume yes, but would be nice to know the actual numbers)
• Are you pretty confident in the test coverage?

[fselmo]

We chatted about this but I'll add it here so we can all think on it. I think in most cases this can be pretty harmless, to make a decision that you are calling the (bytes,bytes) version of the method because the first argument is not encodable as bytes32.

Let's say I thought I did some good math and I ended up padding the value I wanted to pass in here to where it was 33 bytes instead of 32. Then, the method I'm actually calling ends up being (bytes,bytes) with no exception or warning but I thought that it was (bytes32,bytes). I understand that had I actually called the (bytes32,bytes), it would've raised (as per the test below)... but since I didn't I never understood the whole flow here.

I can see this being used as an exploit at the worst case scenario, but also leading to undesired behavior at times on a level below that.

I would prefer a default API that gives me full control and confidence that I'm doing the right thing. If I got an exception here that asked me to explicitly get my function by signature before calling it, I think that would give me more confidence that I'm dealing with exactly the methods I want to deal with.

Some lingering questions for me are. How would we draw these lines? We don't have to be as strict as same # of args in function with same name... but maybe that's a good line to draw?

I also might be OK keeping it like this if we document this well enough. But not a whole lot of people read the docs thoroughly before using the library, so this wouldn't address the issue to a lot of users as well.

[fselmo]

Talking more on this, you're right that we ideally wouldn't want to raise on isValidSignature(string) vs isValidSignature(bytes). We should be able to discern between the two in that case.

I think I'm OK with documenting this well enough and giving users the ability to call the function by the signature should empower them with the right approach for their workflow. I would want to be explicit, whereas another user might want the flexibility of knowing they are calling (bytes,bytes) simply because their first arg is not length 32.

[reedsa]

After profiling the contract code, I found vast improvements from the latest changes here. I wrote a script that only initialized 10 contracts, then called cPython to profile the calls with python -m cProfile -s calls test-contracts.py > temp.txt

Here are my findings running my script:

Version	Num Contract factory calls	Total function calls in script
7.6.0	1130 calls in 0.336 seconds	3945174 function calls (3881644 primitive calls) in 1.263 seconds
This branch	180 calls in 0.003 seconds	2087387 function calls (2024101 primitive calls) in 1.102 seconds

[fselmo]

I can't approve my own PR but this looks good to me once we address the outstanding comments 👍🏼

[reedsa]

@kclowes we'll add benchmarking tests for contracts at a later time, but the coverage is good. Many of the test cases we already had that broke were fixed along the way. Everything has been addressed up to this point so I'm confident in this being released now! Let me know if there's anything else you'd like to check before I merge.

[pacrob]

One note on docs formatting intention, otherwise lgtm!