Add txOverrides option for overriding transaction parameters

[passabilities]

• allows tx overrides object to be passed into the options parameter to use when submitting a tx

Fixes #85

[ericglau]

Thanks for this PR! This looks like a reasonable approach which would address #85. Particularly, since deploy.ts in both Hardhat and Truffle are used for all deployments (including proxies, proxy-related contracts and implementations), setting the overrides there would cover the various deployment transactions.

I’ve made some changes to separate the option type for Hardhat and Truffle, since Truffle does not use ethers.js.
Also removed the .idea folder since that is environment-specific and would be more suitable in a local configuration.

Additional changes:

• The Truffle option still needs a more specific type. Truffle is untyped so this will require adding an interface similar to what is done in truffle.ts.
• Any transactions other than deployments (for example, upgrading a proxy) also need to respect the new options.
  • Hardhat
  • Truffle
• Add tests.
  • Hardhat
  • Truffle
• Add documentation.
• Add changelog entries.

[frangio]

What happens if you just write upgradeTo(nextImpl, overrides)?

[ericglau]

That would cause an error because then overrides appears as an array and Ethers tries to use it as part of the actual function arguments.

We need to spread the array because its element opts.txOverrides is the actual overrides object, and if that is not present, then it will be excluded.

[frangio]

Sorry my question was actually if we write upgradeTo(nextImpl, opts.txOverrides) 🙂

[ericglau]

That doesn't work, but we could use either:
upgradeTo(nextImpl, opts.txOverrides ?? {})
or
upgradeTo(nextImpl, withDefaults(opts).txOverrides)

[frangio]

I'm not sure that these options will work with Truffle, I recall it working weird if you pass an empty object.

[ericglau]

Right, these don't work for Truffle. Will leave them as-is for both Hardhat and Truffle, for consistency.