EIP-1559 transaction support

[mloit]

Well here it is, the long awaited support for EIP-1559 (and other new transaction types)

This is a pretty significant rewrite of the EthereumTransaction core to a more modular approach. With this modular approach, adding new transaction types, in the future, will be much easier (if this PR were to be adopted). This PR does contain some breaking changes, out of necessity, in how you interact with an EthereumTransaction object. As a result of the breaking changes, it may make this PR undesirable. I've done my best to add a deprecated shim layer so that legacy code should still compile and work, albeit with deprecated warnings, with little to no modification.

What this PR brings:

Full encode, decode, signing, and verification of Legacy, and EIP-2718 type transaction envelopes.
Currently EIP-2718 defines two transaction types; EIP-2930 and EIP-1559, both are fully supported for encode, decode, signing, and verification.

I've also built on-top of the excellent work already done by Yaroslav and others for EIP-1559 support (now in PR #510) in the Feature/EIP-1559 branch. So included here is the work already done for the new Gas calculations and block management, though that work is still incomplete and not fully integrated. As it stands now EIP-1559 transactions can be created, signed, and sent, but automatic gas calculation is not implemented.

All parts of the library that rely on EthereumTransaction have been updated as necessary to work with the new Transaction Interface. Though any code that works with gas still only understands and works with the legacy values.

Things needed

Testing, Testing... testing!!! While I've added some tests to validate the decode, verification [and by extension encode] more tests are needed. Preferably made by someone other than me. Not because I'm lazy and don't want to do it, but because I am biased by my interpretation of how things should be. Having someone else who has their own independent interpretation of the specs would help to find any errors in implementation. [though I have tested this code on Rinkeby with good success]

Documentation! As always we need to document how things work. I've added a bunch of quick-help style comments in the code to aide in this direction, but more work, and help, here is needed.

Automatic Gas calculation. This really needs to be complete before we can claim full support for EIP-1559.

Creating Transactions

For the most part things work as they did before. The notable change is you use the TransactionOptions structure to pass the gas and other transaction specific parameters to the transaction object.

    /// Universal initializer to create a new EthereumTransaction object
    /// - Parameters:
    ///   - type: TransactionType enum for selecting the type of transaction to create (default is .legacy)
    ///   - to: EthereumAddress of the destination for this transaction (required)
    ///   - nonce: nonce for this transaction (default 0)
    ///   - chainID: chainId the transaction belongs to (default: type specific)
    ///   - value: Native value for the transaction (default 0)
    ///   - data: Payload data for the transaction (required)
    ///   - v: signature v parameter (default 1) - will get set properly once signed
    ///   - r: signature r parameter (default 0) - will get set properly once signed
    ///   - s: signature s parameter (default 0) - will get set properly once signed
    ///   - options: TransactionObject containing additional parametrs for the transaction like gas
    public init(type: TransactionType? = nil, to: EthereumAddress, nonce: BigUInt = 0,
                chainID: BigUInt? = nil, value: BigUInt? = nil, data: Data,
                v: BigUInt = 1, r: BigUInt = 0, s: BigUInt = 0, options: TransactionOptions? = nil) {

TransactionType is the enum that controls the type of transaction that will be created

public enum TransactionType {
    case legacy
    case eip2930
    case eip1559
}

When using a higher level API, you can still create new transaction types by setting type within the TransactionOptions object you pass. Alternatively you can use the applyOptions function with type set to migrate the transaction type before signing and transmitting.

Direct access to the type specific parameters is no longer available. getOptions() and applyOptions() can be used to query or modify any of those parameters. This is how you will need to access all the gasXXX parameters. A given transaction type will ignore any gas parameters it does not support.

That's all for now

I'm sure there will be questions... ask them below. And please test this code, and comment, and help find the bugs.

I'm not going to mark it as a draft PR for the time being, but I consider it still incomplete, though the core functionality is all there. It's a good start, and I wanted to get it out there so people can start working with it to iron out any issues.

Closes #349

[mloit]

Reverted some of the changes made previously back to what's in develop in preparation for a bit of a refactor on how I handle the transaction parameters. The code base still works, you will just get a lot of deprecated warnings, as most of what I backed out were the external changes I made within the library to interact with EthereumTransaction in the new way. The mechanism that was used, and the warning tells you to use, is being refactored and will be updated in the next few days.

[mloit]

The failure is due to an implementation error in Oracle for legacyGasFees, specifically gasPriceLegacyPercentiles()

[mloit]

Found a workaround/fix. It seems some nodes are reporting a gasPrice value in the JSON for EIP-1159 transactions, even though EIP-1159 transactions have no such field. Oracle appears to depend on this, so the workaround is to store this non-standard value still and report it as gasPrice to satisfy Oracle. This really should be corrected for 3.0, and the workaround removed.