Fix `calculate_max_long` and `calculate_max_short` for accuracy

[jalextowle]

A lot has changed in Hyperdrive over the last few months. We should make sure that the math used in these functions is actually correct and fix any discrepancies that we find. This should address any of the lingering known issues in the SDK.

[dpaiton]

While doing this it would be good to verify that delvtech/hyperdrive#797 and #42 are resolved. This is also related to delvtech/hyperdrive#894.

[wakamex]

crash on calc max short with a high fixed rate of 100%

failing test here: #19

I noticed our fuzz ranges seem too narrow. should we do all of them up to 100% fixed rate? also in some cases fixed rate is not fuzzed.

[wakamex]

crash trying to open long over 70% of the calculated max long after adding liquidity delvtech/agent0@7434b96

[dpaiton]

Related to max short crash report from @slundqui #42

Crash Report

Description

Calling calc_max_short in the rust SDK breaks with an arithmetic operation overflow error

Expected Behavior

calc_max_short doesn't crash

Actual Behavior

calc_max_short crashes with an error

Steps to Reproduce

1. Deploy a hyperdrive pool with a position duration of a week, target fixed rate of 5%, initial liquidity of 100,000,000 base. This results in a time_stretch of 0.00087344336337973.
2. Call calc_max_short with a budget of 100,000 base.

Playing around with parameters, it seems that calc_max_short doesn't crash when the position duration is > 29 days, but does crash when position duration <= 28 days.

Additionally, with a position duration of a week, adjusting the budget to be 1e9 base doesn't crash, but setting a budget of 100,000 base does crash.

Getting another error in calc_max_short:

pyo3_runtime.PanicException: max short exceeded budget

Here are the parameters when calling get_max_short:

pool_config = PoolConfig(baseToken='0x5FbDB2315678afecb367f032d93F642f64180aa3',
           linkerFactory='0xDc64a140Aa3E981100a9becA4E685f962f0cF6C9',
           linkerCodeHash=b'uK(\x17\x1a\xf2\xb7q\xa3\x126\xd9\x1d;\xfd\x93'
                          b"2\xda\xa1\xde9\x80\x94D1L\r\xfd6\xfb'\xeb",
           initialSharePrice=1000000000000000000,
           minimumShareReserves=10000000000000000000,
           minimumTransactionAmount=1000000000000000,
           positionDuration=604800,
           checkpointDuration=3600,
           timeStretch=873443363379730,
           governance='0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
           feeCollector='0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
           fees=Fees(curve=10000000000000000,
                     flat=500000000000000,
                     governanceLP=10000000000000000,
                     governanceZombie=100000000000000000))

pool_info = PoolInfo(shareReserves=100000166168989209376245204,
         shareAdjustment=-72597894831832927,
         zombieBaseProceeds=0,
         zombieShareReserves=0,
         bondReserves=299612105618339733502453961,
         lpTotalSupply=100000107244738255324956936,
         sharePrice=1000165648843736100,
         longsOutstanding=61284946301931302384,
         longAverageMaturityTime=1706232591357648602037963923,
         shortsOutstanding=12309486122233927680,
         shortAverageMaturityTime=1706241600000000000000000002,
         withdrawalSharesReadyToWithdraw=0,
         withdrawalSharesProceeds=0,
         lpSharePrice=1000165648867533483,
         longExposure=61284946301931302384)

budget = 130080851117999367591

open_share_price = 1000165648843736100

checkpoint_exposure = 0

maybe_conservative_price = None

maybe_max_iterations = None

[wakamex]

copied from @slundqui's issue:

absolute_max_long is failing due to target_share_reserves < effective_share_reserves with arithmetic operation overflow here:
https://github.com/delvtech/hyperdrive/blob/1576e4c4368dd9c21b2df60274f223271e793d46/crates/hyperdrive-math/src/long/max.rs#L214

This is the pool state that caused this issue:

pool_config = {
   base_token='0x610178dA211FEF7D417bC0e6FeD39F05609AD788',
   vault_shares_token='0xB7f8BC63BbcaD18155201308C8f3540b07f84F5e',
   linker_factory='0x5FbDB2315678afecb367f032d93F642f64180aa3',
   linker_code_hash=b'\x91\xa6<\xce\xc3\xbbXQ\xa0\x88\xc4G\xd5\xd3@`4AP\xbe+q\xac`\xc1\x97\x82\x7f\xd1HIL',
   initial_vault_share_price=FixedPoint("1.0"), minimum_share_reserves=FixedPoint("0.206282109669978528"),
   minimum_transaction_amount=FixedPoint("2.4934863032025728"),
   position_duration=30801600,
   checkpoint_duration=82800,
   time_stretch=FixedPoint("0.168128366020933774"),
   governance='0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
   fee_collector='0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
   sweep_collector='0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266',
   fees={
      curve=FixedPoint("0.063774932363567072"),
      flat=FixedPoint("0.180852177854770176"),
      governance_lp=FixedPoint("0.19281944111115744"),
      governance_zombie=FixedPoint("0.052803595874591256")
   }
}

pool_info = {
   share_reserves=FixedPoint("26176.625462115783671808"),
   share_adjustment=FixedPoint("0.0"),
   zombie_base_proceeds=FixedPoint("0.0"),
   zombie_share_reserves=FixedPoint("0.0"),
   bond_reserves=FixedPoint("73185.723713861986104902"),
   lp_total_supply=FixedPoint("26176.41918000611369328"),
   vault_share_price=FixedPoint("1.000001457064193671"),
   longs_outstanding=FixedPoint("0.0"),
   long_average_maturity_time=FixedPoint("0.0"),
   shorts_outstanding=FixedPoint("0.0"),
   short_average_maturity_time=FixedPoint("0.0"),
   withdrawal_shares_ready_to_withdraw=FixedPoint("0.0"),
   withdrawal_shares_proceeds=FixedPoint("0.0"),
   lp_share_price=FixedPoint("1.00000145706419367"),
   long_exposure=FixedPoint("0.0")
}

[jalextowle]

That is a really high flat fee. We should consider bumping that down in the fuzzed range.