Add runtime API ConvertTransactionRuntime API

[librelois]

Closes #508

Introduces a new runtime API (ConvertTransactionRuntimeApi) to convert an ethereum transaction to an Extrinsic.

This is necessary for production networks that want to move to eth transactions V2 without a breaking update (like Moonbeam).

The TransactionConverter is still used if the runtime API is not present.

For projects that integrate the runtime API into their runtime, a TransactionConverter must still be provided to satisfy the rust traits bound, which is why a NoTransactionCorverter type was introduced.

[sorpaas]

Consider changing this to with RLP Vec<u8> as input, and return Option<Extrinsic> where None indicates that the conversion failed.

Ethereum transaction's RLP encoding is backward and future compatible, but not really the SCALE encoding, as that's internal. Doing the above ensures that when runtime updates to support a new transaction type, you can immediately use it without waiting for old nodes to update. With this you can also remove the versioning.

Also, is there a particular reason that this isn't put into EthereumRuntimeRPCApi?

[sorpaas]

Hmm I realized that our EthereumRuntimeRPCApi is not forward compatible anyway, so the above (using RLP Vec<u8> as input) may not provide much benefits.

The other points still stands -- maybe consider moving this to EthereumRuntimeRPCApi.

[librelois]

We decided to have it in a separate trait so that the client can ask if the API is present or not.
Indeed, substrate does not allow to ask if a particular method of a runtime api is present or not.

[sorpaas]

Is this actually used? Do we actually have a situation where transaction conversion is just not possible or something?

[JoshOrndorff]

If you have this type, then why do you still have an Option<_> in Eth::new?

[JoshOrndorff]

Oh, I get it. I use this only as a type parameter. and use None as the value. That's why it's not instantiable.

[sorpaas]

I talked with @tgmichel and let's keep it the current way, as the code is already semi-used in production.

[MOZGIII]

I'd like to highlight some differences compared to #558:

• This version is more verbose, and there's a lot more logic that's copy-pasted around;
• In the Backport of runtime transaction converter #558, the converter is made to be fallible, which allows to implement it over the client if the Runtime API needed;
• The fallback logic is hardcoded here, and represented via Option, while in the Backport of runtime transaction converter #558 version it can just be a variant of TransactionConverter implementation - which makes way more sense for networks that start from scratch and don't need this legacy weight - they'd just use the API version from the genesis.

It is very sad to see that #558 didn't got the attention it deserved.

[librelois]

I'd like to highlight some differences compared to #558:

* This version is more verbose, and there's a lot more logic that's copy-pasted around;

* In the [Backport of runtime transaction converter #558](https://github.com/paritytech/frontier/pull/558), the converter is made to be fallible, which allows to implement it over the client if the Runtime API needed;

* The fallback logic is hardcoded here, and represented via `Option`, while in the [Backport of runtime transaction converter #558](https://github.com/paritytech/frontier/pull/558) version it can just be a variant of `TransactionConverter` implementation - which makes way more sense for networks that start from scratch and don't need this legacy weight - they'd just use the API version from the genesis.

It is very sad to see that #558 didn't got the attention it deserved.

Sorry @MOZGIII , I hadn't seen your PR, and we had to implement it in a hurry to solve a problem in production :/

Your PR seems to be better designed, you can open a new one to improve the implementation, and tag me to review it :)
My only constraint is that it has to be compatible with what is already in production, so if the runtime API changes you have to upgrade to version 3 :)