Fix remaining no tx assigns

[janndriessen]

Summary of Changes

Fixes #712

• Fixes all remaining ERC's mentioned in WriteOperation.transaction ignores ERC*.transaction settings #712
• Some additional (linting) clean ups and fixes for warnings

By submitting this pull request, you are confirming the following:

• I have reviewed the Contribution Guidelines.
• I have performed a self-review of my own code.
• I have updated my repository to match the develop branch.
• I have included test data or screenshots that prove my fix is effective or that my feature works.
• I have checked that all tests work and swiftlint is not throwing any errors/warnings.

[yaroslavyaroslav]

Just wonder is it all of them? Like do we really using WriteOperation only in ERC+20 and ERC+721 classes and nowhere else?

[janndriessen]

Just wonder is it all of them? Like do we really using WriteOperation only in ERC+20 and ERC+721 classes and nowhere else?

ser, this is work progress [WIP] Just created a PR to run the actions cause I'm lazy. 😄

[JeneaVranceanu]

TL;DR - this PR is fine to merge but in some future PRs, we must remove these public var transaction: CodableTransaction variables as they only create side effects.

---

@janndriessen What concerns me about this commit (a20b1c4) is that the callOnBlock value can be modified from the outside before any particular call and when we actually execute any of the read operations we can be a wrong value.

Here is a pseudocode example:

let someErc = SomeERC.init(...)
someErc.transaction.callOnBlock = .exact(555_111)
/// This will probably fail due to `callOnBlock` but also trigger setting
/// `someErc.transaction` to `someErc.contract.transaction`
try? await someErc.executeWriteTransaction()
/// Expected to be called on the latest block but instead uses block number 555_111
try? await someErc.readSomeData()

These types of bugs are the primary reason why we should remove all public var transaction: CodableTransaction variables.

[janndriessen]

TL;DR - this PR is fine to merge but in some future PRs, we must remove these public var transaction: CodableTransaction variables as they only create side effects.

@janndriessen What concerns me about this commit (a20b1c4) is that the callOnBlock value can be modified from the outside before any particular call and when we actually execute any of the read operations we can be a wrong value.

Here is a pseudocode example:

let someErc = SomeERC.init(...)
someErc.transaction.callOnBlock = .exact(555_111)
/// This will probably fail due to `callOnBlock` but also trigger setting
/// `someErc.transaction` to `someErc.contract.transaction`
try? await someErc.executeWriteTransaction()
/// Expected to be called on the latest block but instead uses block number 555_111
try? await someErc.readSomeData()

These types of bugs are the primary reason why we should remove all public var transaction: CodableTransaction variables.

For sure you don't have to convince me that these classes have bad designs.

Zooming out, I wouldn't even concentrate on adding/maintaining such classes - for me this is convenience/ nice to have.

If the library is built modular enough, an ERC class like this should be easily buildable by anyone themselves.

[janndriessen]

Also, all this kind of things should go on a list for future design choices for 4.x.x or other future versions.