Require input and output amounts for raw interactions

[nlordell]

This PR augments interaction data to also include input and output amounts. This will be required by the driver in order to verify token conservation across tokens and orders.

Test Plan

Added unit test to verify de-serialization. For now, there is no new logic changes.

Release notes

This PR introduces changes to the HTTP solver interface. Note that the API was kept backwards compatible to allow solver implementations time to adapt to the new API. These changes will be made required after a certain amount of time (since they are required for validating new solver rules around local and global token conservation).

[MartinquaXD]

The code itself looks good (nice refactor of TokenAmount).

verify token conservation across tokens and orders...

Could harm be done by solvers lying about the input and output amounts?
I guess we would have to simulate each interaction to know whether those values are correct, right?

[josojo]

Looks good!

[nlordell]

Could harm be done by solvers lying about the input and output amounts?

Yes. What is unclear is whether or not we should verify this upfront (by simulating as you suggested) or if we should slash solvers that misbehave.

[codecov-commenter]

Codecov Report

Merging #194 (f4ac00d) into main (56ae162) will increase coverage by 0.08%.
The diff coverage is 95.45%.

❗ Current head f4ac00d differs from pull request most recent head 997edc0. Consider uploading reports for the commit 997edc0 to get more accurate results

@@            Coverage Diff             @@
##             main     #194      +/-   ##
==========================================
+ Coverage   64.35%   64.44%   +0.08%     
==========================================
  Files         189      189              
  Lines       38896    38988      +92     
==========================================
+ Hits        25032    25125      +93     
+ Misses      13864    13863       -1     

[vkgnosis]

I guess this has been discussed already but doesn't this limit what an interaction can do in a potential important manner? What if you have an interaction with one input amount and two output amounts or vice versa? What if a first interaction facilitates a next interaction and either one alone doesn't have the proper in and out amounts?

[nlordell]

What if you have an interaction with one input amount and two output amounts or vice versa?

Good point. I guess these should be inputs: Vec<TokenAmount> and outputs: Vec<TokenAmount>.

What if a first interaction facilitates a next interaction and either one alone doesn't have the proper in and out amounts?

Then, given ☝️, the first interaction be modelled as {... input: [], output: [] ...} and the second one containing a list of all input and output token amounts.

[nlordell]

I changed this PR to make the changes backwards compatible. This way we can start implementing the external solver checks (local and global token conservation) without breaking existing solvers while also allowing our existing solvers to change to use this new API.

@MartinquaXD would appreciate a re-review.

[MartinquaXD]

Does still look good to me. 👍