feat: Add support for function input/output encoding/decoding

[davebryson]

Motivation

Added support for Function input encoding and output decoding. This is in reference to issue #210

Solution

Added trait FunctionExt that defines 2 methods: encode_input(...) and decode_output(...) and an implementation of the trait for json_abi::Function. Currently this resides in resolve.rs.

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[prestwich]

discussing this approach internally and will loop back

[davebryson]

As I dig in a bit more, to grok all of core, I'm wondering if SolType is intended as a (better) replacement for ethabi Token. If that's the case, should encode_input() take a SolType as arguments vs DynSolValue?

[DaniPopes]

ethabi::ParamType -> DynSolType
ethabi::Token -> DynSolValue

[prestwich]

As I dig in a bit more, to grok all of core, I'm wondering if SolType is intended as a (better) replacement for ethabi Token. If that's the case, should encode_input() take a SolType as arguments vs DynSolValue?

The problem with doing this is that SolType types must be known at compile time. This means that they can't be used with runtime supplied schema. So if you have a Json ABI Function at runtime, you need DynSolValue and DynSolType, and cannot use SolType

[davebryson]

ethabi::ParamType -> DynSolType ethabi::Token -> DynSolValue

Ok. I'm on the right track then. However, at a higher level, I can still envision the need for something like ethers::Tokenizable to go to and from DynSolValue.

[prestwich]

implementing Into<DynSolValue> seems to be sufficient? 🤔

[DaniPopes]

Thanks, will touch up this PR in a follow-up. (#243)