Think about how to choose constant params like BUY_SELL_ADJUSTMENTS_HALF_LIFE

[jacob-eliosoff]

1. Perhaps also revisit MIN_FUM_BUY_PRICE_HALF_LIFE and MAX_DEBT_RATIO (and maybe more?), but especially BUY_SELL_ADJUSTMENTS_HALF_LIFE. Right now the latter is 1 minute: I've been pondering whether we should consider making it longer - maybe even much longer, like 30-60 minutes. Basic tradeoff:

• A short (eg ≤ 1 min) half-life means that, after eg a long-ETH operation (burn/fund) pushes up the price (the "sliding price" effect), the price drops back towards the raw oracle price faster. This saves the next buyer fees, but means that when the oracle price is slow/off, traders get more chances to exploit it.
• A long (eg ≥ 10 min) half-life means that the sliding price takes longer to gravitate back to the oracle price after trades push/pull it away. This may inconvenience traders (higher fees), but also protects the system from arbitrage during periods where the oracle price is out of whack.
  
  We probably want our v1 to prioritize safety of the system over user fees: anyway patient users can wait to do their ops during low-activity periods, during which the adjustments will be slight and price will be close to the raw oracle price. So, we should probably extend the half-life to eg 10 minutes, or something.

2. An added wrinkle here is that we have two adjustments, one for mint/burn, another for fund/defund. So if, eg, there have been more mints than burns recently, that will push down the sell price used for mints and defunds; and if there have been more funds than defunds, that will push up the buy price used for burns and funds. If both of these have happened recently (more mints than burns and more funds than defunds), then fees will effectively be high for all operations.
   
   I did this, rather than have a single adjustment based on the total net of recent long-ETH vs short-ETH operations, because it's not trivial to net eg a short-ETH mint against a long-ETH fund. If 10 ETH has been passed to mint and 5 ETH to fund, that could add up to net long ETH in total or net short, since fund is effectively a leveraged buy - it depends on the current debt ratio, etc...
   
   Perhaps in the future we can save users fees by calculating this offset carefully and boiling it down to a single long-or-short adjustment, but for now I did the safe thing and kept the two adjustments separate: long-ETH ops (burn/fund) will be more expensive if either more burns than mints have been done recently, or more funds than defunds.