fix: lp position withdraw causes negative liquidity values

[vacekj]

Describe your changes

Issue ticket number and link

Checklist before requesting a review

• I have added guiding text to explain how a reviewer should test these changes.

• If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

  REPLACE THIS TEXT WITH RATIONALE (CAN BE BRIEF)

[conorsch]

Refs #5208. However, as discussion in that ticket shows, the motivation to fix this logic bug was to unblock tokenomics development, and we now believe devs should stay away from the total_unstaked_supply tables as deprecated.

Still, this is indeed a logic bug, and I think we should either fix it or else remove the relevant code, as @cronokirby suggested.

Also, any fixes to logic like this should be targeting the main branch, not the protocol/lqt_branch, because the fix applies to all historical events.

[cronokirby]

I'm not sure there's a difference in behavior here.

The relevant logic is:

            (true, None, new) => (-(new.r1.value() as f64), -(new.r2.value() as f64)),
            (_, None, new) => ((new.r1.value() as f64), (new.r2.value() as f64)),
            (_, Some(old), new) => (
                (new.r1.value() as f64) - (old.r1.value() as f64),
                (new.r2.value() as f64) - (old.r2.value() as f64),
            ),

So turning (true, None, Some(reserves)) into (false, Some(reserves), 0) should result in the same values, i.e. -reserves

[conorsch]

I'm not sure there's a difference in behavior here.

Indeed, I'm still seeing negative values after running this changeset against mainnet event data:

penumbra_raw=# SELECT um, auction, dex, arb, fees
       FROM supply_total_unstaked
       ORDER BY height DESC
       LIMIT 1;
       um       |   auction   |     dex      |     arb     |   fees
----------------+-------------+--------------+-------------+-----------
 80982158646814 | 24571209329 | -34236022151 | 62870499597 | 353350630
(1 row)

N.B. although the database name in the output above is penumbra_raw, it's really a pindexer database.