Enable arbitrary contract calls on /construction/metadata

[gqln]

In order to support transaction construction for arbitrary contract calls, we're making the following changes:

The /construction/metadata endpoint will now, given the following arguments...

- from:   <caller address>              (string)    // "0xabcd...."
- to:     <contract address>            (string)    // "0xabcd...."
- method: <method signature>            (string)    // "deploy(uint8,address,bytes32)"
- args:   [<already_encoded_args_data>] ([1]string) // ["0xabcd...."] if args_encoded is true
          OR
          [<arg1>, <arg2>, ...]         ([]string)  // ["5","0xabcd...",...] if args_encoded is false
- args_encoded:                         (bool)
- amount: <amount>                      (int)

...return the corresponding valid TxMetadata object.

This behavior aligns with other EVM-compatible rosetta implementations (Inphi/optimism-rosetta#103, https://github.com/maticnetwork/polygon-rosetta/pull/46), as well as rosetta-geth-sdk, which all support both argument encoding formats.

To support this functionality while reducing internal changes, CeloMethod now additionally supports 'unregistered' methods, which are identified by method signature.

[palango]

Hi @gqln . Thanks for creating this PR! I left some comments inline and have some more general points below.

• Linting fails in CI, please have a look and fix that.
• The commit message of the second commit is truncated.
• What's the thinking behind offering both encoded and unencoded parameter lists? Is this a requirement coming from other systems? Ideally we would decide on one representation and use that exclusively.
• What are the next steps here? Do you plan to do additional work on this?

[gqln]

Hi @gqln . Thanks for creating this PR! I left some comments inline and have some more general points below.

• Linting fails in CI, please have a look and fix that.
• The commit message of the second commit is truncated.

Thanks for the review @palango! I've resolved these first two items and your comments.

What's the thinking behind offering both encoded and unencoded parameter lists? Is this a requirement coming from other systems? Ideally we would decide on one representation and use that exclusively.

Yes, we need both encoding options for our use case. The other EVM-compatible rosetta implementations we're using (Inphi/optimism-rosetta#103, https://github.com/maticnetwork/polygon-rosetta/pull/46, flare-foundation/flare-rosetta#16, ava-labs/avalanche-rosetta#223), as well as rosetta-geth-sdk also support both argument encoding formats.

What are the next steps here? Do you plan to do additional work on this?

We don't require any changes beyond this PR for our use case, so there's no additional work planned for now.

[palango]

Looks good.

[palango]

We don't require any changes beyond this PR for our use case, so there's no additional work planned for now.

Do you require a release from our side or do you build it yourself?

[gqln]

We don't require any changes beyond this PR for our use case, so there's no additional work planned for now.

Do you require a release from our side or do you build it yourself?

@palango Yes, that would be perfect! Could you make a new release?

[palango]

@gqln Released a new beta here: https://github.com/celo-org/rosetta/releases/tag/v2.1.0-beta
Let me know if you run into any problems.