Add ValueRange type

[ethanfrey]

Requires #52 (merge that first)

This is inspired by the work in #49 about defining possible ranges of values as a lightweight partial lock for in-flight IBC transactions

Basic functionality is there and tested. It would be good to have some more realistic tests cases to ensure this API would be useful in real conditions

[maurolacy]

Looks good, but it's difficult for me to see how useful this is until hitting the real use case.

What we need is a couple of values that we can keep track against a couple of min (typically, zero) and max (typically, max cap?), values.

A given set of pending unordered TXs will be valid (that means, it can be accepted for processing without locking), if:

• All of the reduce stack ones are above the min (when / if successfully processed), in the face of all of the increase stack ones failing.
• Vice versa: All of the increase stack ones are below the max (when / if successfully processed) in the face of all the decrease stack ones failing.

Not difficult to reason about, actually. Good if the ValueRange type helps us in that regard.

[ethanfrey]

That is exactly the use case I was considering. And I think done with this API. I need to make better examples and likely adjust a bit.

A ValueRange keeps the min and max of all pending either succeeding or failing. We can also sum a number of them (think Sum over all liens to find total_slashable). And get the max of the max and min of the min.

It allows implementing a lock not on one element (eg user's OSMO balance), but on a portion of one element (500 OSMO of the user's balance). Want to try to write some such example as a test and give feedback on the API?

[maurolacy]

I have a rough idea on how to implement this:

Based on a set of pending TXs. And (I think) we don't need locking, but just a check before accepting a new TX: It either passes (is compatible with the current set of pending TXs, in the sense of not exceeding the min and max caps). Or, it fails, and is rejected upfront.

Are you proposing using the Lockable type to try and define the amounts associated with the set of pending TXs? Or are you proposing to use locking if the compatibility check fails?

I can try implementing this on the external-staking contract, and we can discuss there over the PR if you want.

[ethanfrey]

I think we need to agree on the IBC docs and add IBC before we start using this in contracts.

My idea is rather than have to reason though every possible transaction that touches the same contracts as an IBC transaction, the IBC transaction just locks the critical sections it will update (either a WriteLock, or a ValueRange).

Then anything that could conflict would error. In lockable, this would be a read, a write, or another lock on the same value. With ValueRange, we reserve some more of that value, and it fails if any point in the range (any combination of pending tx succeeding or failing) would violate some limit (eg below 0 or above some max cap, eg collateral)

The main point is to modify the values such that all tx will execute this lock-check code. And not having to go through every path and making sure we add checks

[JakeHartnell]

Looks good! Another useful package.

PR to fix clippy errors: #56

[maurolacy]

LGTM. Some comments on usability / API design, as I still find it confusing.

[ethanfrey]

Okay, I made suggested improvements.
Adding another PR with examples to shake it out in real-world usage