[API-3583] Track tx costs

[mattac21]

This PR has the tx verifier store tx costs in uusdc in the submitted txs table so that solvers are able to track their actual net profit (profit from orders minus tx costs). To do this, I moved the evm tx price oracle to a more generic oracle package, and removed evm specific wording from it (since really all it did was a coin gecko lookup and then decimals conversion to uusdc). The tx verifier uses this to now calculate the tx price in uusdc.

This also changes the fund rebalancer so that it submits its txs to the submitted txs table so that they can be priced. To do this, a rebalance id is added to the submitted txs table. There is also an issue I encountered where we create approval txs before we actually create the row in the rebalance transactions table, however the approval txs should be linked to that rebalance tx in the submitted txs table. To get around this we create a blank rebalance tx before the approval tx (or return an already created blank rebalance tx, if we didn't submit previously due to gas costs), and then update the blank rebalance tx with the tx hash and amount once the rebalance tx is submitted on chain.

[dhfang]

LGTM! I dont think we put fund rebalancer txs in the submitted txs table right for the tx verifier. Down for you or someone else to add that in a separate pr if you want to merge this.

[nadim-az]

Changes lgtm, but the creation of the empty rebalance tx in the submitted txs table so it's available for the approval tx to link to is kind of confusing. Can we instead update the approval tx instead after the rebalance tx is created? that would be simpler to follow imo

[mattac21]

Changes lgtm, but the creation of the empty rebalance tx in the submitted txs table so it's available for the approval tx to link to is kind of confusing. Can we instead update the approval tx instead after the rebalance tx is created? that would be simpler to follow imo

agree that would be easier to follow, and I did think about that scenario but iirc I didnt go with that because of the scenario where we may submit an approval tx and then the solver crashes. in this case we would have no way to know that that approval tx in the submitted txs table is meant to go with the rebalance once the solver starts back up and the solver submits the actual rebalance tx. if you have some ideas on a good way around that tho i would be good to implement that

[nadim-az]

Changes lgtm, but the creation of the empty rebalance tx in the submitted txs table so it's available for the approval tx to link to is kind of confusing. Can we instead update the approval tx instead after the rebalance tx is created? that would be simpler to follow imo

agree that would be easier to follow, and I did think about that scenario but iirc I didnt go with that because of the scenario where we may submit an approval tx and then the solver crashes. in this case we would have no way to know that that approval tx in the submitted txs table is meant to go with the rebalance once the solver starts back up and the solver submits the actual rebalance tx. if you have some ideas on a good way around that tho i would be good to implement that

uhh i spent some time on this and any solutions I came up with would also just add complexity, what you have now is the simplest approach i think. thanks! 🙏

[dhfang]

lgtm!