Support EVM smart contract DDO clients

[kacperzuk-neti]

Checklist

• This is not a new feature or an enhancement to the Filecoin protocol. If it is, please open an FIP issue.
• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the Boost forum and select the category as Ideas.
• I have a specific, actionable, and well motivated feature request to propose.

Boost component

• boost daemon - storage providers
• boost client
• boost UI
• boost data-transfer
• boost index-provider
• Other

What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.

FIDL is working on smart contracts that would enforce some rules on how clients can use their datacap (for example, restrict to selected storage providers). This is implemented as EVM contracts that act as a Verified Client (contracts receive the DataCap) and the actual client has to call them to create DDO allocations.
We expect that these contracts will become widely used.

Describe the solution you'd like

As we expect these contracts to be widely used, having support for them in boost will make clients' lives easier.

My proposal is to add a new option to boost allocate command: --evm-client-contract. When the option is provided, instead of calling transfer method on datacap actor directly, it should invoke transfer method on the provided EVM contract. While parameters to the EVM contract are semantically the same, EVM contracts require different encoding.

I plan on implementing this and submitting a PR to boost. Before I do that though, I'd like to get a green light for:

1. The idea of implementing this in boost in the first place.
2. We need a solution for encoding EVM calldata. My proposal is to add a new dependency, go-eth, that makes this trivial (see sample usage in contract-metaallocator-cli).

Describe alternatives you've considered

Instead of using go-eth for encoding, I've considered:

• generating contract bindings using geth: https://geth.ethereum.org/docs/developers/dapp-developer/native-bindings#generating-bindings . That seems like an overkill for just 1 method in 1 contract.
• writing a custom utility function, with no new external dependencies, that would encode the call to the contract. That seems like reinventing the wheel that would require extensive tests.

Additional context

Current implementation of the client contract: https://github.com/fidlabs/contract-metaallocator/blob/main/src/Client.sol#L59