Refactor updater to use ethabi-derive

[axelchalon]

Use ethabi-derive (with call function @ this branch: https://github.com/paritytech/ethabi/pull/62) to generate the updater contract, rather than using the auto-generated operations.rs contract file. The ABI passed to use_contract! is the same as before.

Todo:

• Needs testing! @lght is currently writing tests on the updater based on master Updater unit tests #6913 ; we'll want to make sure they also pass on this branch.

Before merging:

• Update ethabi crates on crates.io (https://github.com/paritytech/ethabi/pull/62) so we can update the Cargo.toml ethabi dependency to a regular one

Issues/questions:

• Right now ethabi-derive call returns an ethabi::Result (i.e. Result<_, ethabi::Error>). However, updater.rs expects Result<_, String>, so I need to map_err the ethabi::Error into a string each time (when using ? for example); not sure if this is optimal. Let me know if this should be done another way; I imagine this will change with the error-chain refactoring by Marek.
• Why is collect_release_info a static method? I kept it this way but I'm wondering why it cannot be made a regular method so we don't have to pass the contract and the call method to it.
• In the previous version (master), the generated contract had specific input/output types based on the ABI (e.g. (u32, u8, u32, bool)). ethabi-derive currently uses pretty generic input/output types (e.g. (ethabi::Uint , ethabi::Uint , ethabi::Uint , bool)). This creates the need for quite a bit of boilerplate to convert the types to and fro (I imagine this will also be linked with Marek's refactoring for unifying the types). Same for strings; they need to be converted to a hash before being passed as an input. Wouldn't it better if the functions generated by ethabi-derive took care of this and matched the function signatures in the ABI more closely?

---

This change is 

[lght]

Couple of minor grumbles about dependency checksums and abstracting do_call's type. Other than that, the changes look great!

[lght]

Could you abstract do_call's type with a type alias? Maybe above UpdateFilter you could add:
pub type DoCallFn = Fn(Vec<u8>) -> Result<Vec<u8>, String> + Send + Sync + 'static>

[axelchalon]

Sounds good!

[lght]

Will checksums automatically get added to the ethabi dependencies? I'm not very familiar with how checksums are calculated/stored for github dependencies.

[axelchalon]

I don't know, I'm not familiar with them either, but we will switch to a regular dependency (on crates.io) once the ethabi branch is merged; this will probably add the checksums again?

[lght]

Yeah, pretty sure that crates.io includes the checksum with the crate. If this will be pulling from crates.io on merge, I have no issues with the missing checksum here. Think cargo pins the a release hash to the github url anyway, so secure enough for dev purposes. Just didn't want it to get rolled into master that way

[axelchalon]

I'm waiting for https://github.com/paritytech/ethabi/pull/62 to be merged and then I'll update the dependency in this PR.

[lght]

Ok sounds good. Everything else looks great. So far from the tests I've written, your changes are easy to incorporate.

[debris]

I've added paritytech/core-devs to the owners list of ethabi_derive. I've also released 4.2, so feel free to use it instead of github repo ;)

[5chdn]

A0 and A3 labels are clearly conflicting :)

[axelchalon]

I don't plan to make modifications to the code, so reviewing can happen now, but I need to wait for the tests #6913 to be written until this can be merged ^^ I guess I'll ask for a review once this PR is ready to get merged :)

[tomusdrw]

On ice, waiting for #6913

[debris]

I'll take it from here