Circuit Breaker data

[EndymionJkb]

Starting with the storage, this sets/retrieves circuit breaker data and performs all associated error checks and computations (e.g., bounds with changing weights).

I have a lot of simulations to go with this (see #1399 ), and have some concerns, but this is the current state of the design.

It involves some fairly heavy computation (exponentiation), and this might be a pre-optimization, but I cache values so that computing the bounds is cheap if the weights aren't changing (e.g., if they get reset after a rebalance, and everything is fixed for the next three months).

There's some complexity in storing/compressing all this to fit, and some limits to the input ranges arise from it (noted in the fuzz tests). The limits seem reasonable for normal operation, though, especially if we are only setting lower bounds, as seems to be the current consensus.

If we didn't optimize for changing weights (e.g., we expect weights to be changing most of the time), it would only need to store the ref price and bounds: 128 bits for the price, and 64 each for the bounds.

[EndymionJkb]

Inspired by #1816 , I have a version of this with a 66-bit weight complement that likewise removes compression, and contains a detailed range analysis (to remove compression from the other fields as well).

[TomAFrench]

I checked and we can actually remove CircuitBreakerParams as we don't get stack issues if we just pass in the the 4 fields separately. This could help readability and simplify the integration code inside ManagedPoolSettings.

[EndymionJkb]

I checked and we can actually remove CircuitBreakerParams as we don't get stack issues if we just pass in the the 4 fields separately. This could help readability and simplify the integration code inside ManagedPoolSettings.

Gone!