Add support for equivalent values to ValueView

[hdevalence]

I'm not sure if the EquivalentPrice should also be defined in the asset proto package rather than alongside the TxP? I filled in an implementation that inserts equivalent values into TransactionViews but I realized that because it relies heavily on the TxP it may not be directly useful for the web extension use cases, which so far seem mostly about balances (?).

However, while doing that I realized that in the context of viewing a transaction, it doesn't really make sense to just have an "equivalent value" on its own, so I added an as_of_height to allow indicating when the prices were relevant.

[hdevalence]

Closes #3838 whenever we work out what the right design is

[grod220]

I think this makes sense. As we are scanning through blocks, we'll use the new prices: Vec<EstimatedPrice> available in the transaction (the node provides this right?) and save these to our DB. Here's where we save the transaction. It shouldn't be hard to also have an additional write for prices in another table (or maybe do a special kind of index).

Then, upon request for balances, we'll fill out the ValueViews by querying the DB & applying some filtering (specific numeraire, recency/confidence, etc) and making the conversion like you did in the view_value method.

[hdevalence]

I think this makes sense. As we are scanning through blocks, we'll use the new prices: Vec<EstimatedPrice> available in the transaction (the node provides this right?) and save these to our DB.

Well, I'm not 100% sure if we want to do this, since it gets to the problem that asks for an as_of_height: when viewing a transaction, what are the right prices to display? The historical ones? The current ones? How would we convey the time of the price in the UI?

I think this would need a bit more product thinking than we've done so far, it seems like a bit of a rabbithole, so we might be better off not doing anything for now and only focusing on the other parts of the RPC (like balances) which are inherently "current" data. But that's exactly the use case the current state of this PR doesn't address, since it only works on transactions.

Then, upon request for balances, we'll fill out the ValueViews by querying the DB & applying some filtering (specific numeraire, recency/confidence, etc) and making the conversion like you did in the view_value method.

Right, the issue I was pointing to is that (in the current state of this branch) this isn't possible, since the equivalent values can only be generated in the context of a Transaction.

[hdevalence]

I updated the PR to make it possible to use the estimated prices independently of the TxP mechanism. I think it's good to go now.

The breaking change notifications from the proto lint is a false positive, it's comparing to the previous run rather than comparing to the pre-PR state.

[grod220]

I updated the PR to make it possible to use the estimated prices independently of the TxP mechanism. I think it's good to go now.

On the web side of things, it seems we'd just need to adjust the price sourcing (versus relying upon tx). For example, we'd have to do something like:

• Scan through blocks
• If swapOutputs detected, loop through them and save swap to database
  • Table: "SWAP_OUTPUTS"
  • Fields:
    • in: Amount (delta1 - lambda1)
    • out: Amount (delta2 - lamda2)
    • height: BigInt
    • tradingPair: TradingPair
• On Balances rpc call, query db

[hdevalence]

I updated the PR to make it possible to use the estimated prices independently of the TxP mechanism. I think it's good to go now.

On the web side of things, it seems we'd just need to adjust the price sourcing (versus relying upon tx). For example, we'd have to do something like:

* Scan through blocks

* If `swapOutputs` detected, loop through them and save swap to database
  
  * Table: "SWAP_OUTPUTS"
  * Fields:
    
    * in: Amount (delta1 - lambda1)
    * out: Amount (delta2 - lamda2)
    * height: BigInt
    * tradingPair: TradingPair

* On Balances rpc call, query db

@grod220 I think penumbra-zone/web#556 is a more general design