Add SumObserver and UpDownSumObserver instruments

[lzchen]

Resolves [#755] and [#756]

Abstracts Observer instrument as a base class for all asynchronous instruments.

SumObserver and UpDownSumObserver are also cumulative, so they use the LastValueAggregator to record.
Observed values must also be non-decreasing, compared to the previous observed value for SumObserver. Observed values can be any value for UpDownSumObserver .

[aabmass]

LGTM!

[aabmass]

I think you need to update the ObserverT TypeVar in this file

[lzchen]

Currently we have ObserverT = TypeVar("ObserverT", bound=Observer). I believe as long as the class used is a subclass of "Observer" this definition should be accurate?

[aabmass]

Oh sorry you're right!

[toumorokoshi]

Overall a couple minor changes, but I think the code does as expected.

Unrelated to this PR per se, but: I feel like both of these observers Sum and UpDownSum, aren't super valuable.

At the end of the day, all these things do is provide a sanity check for a developer who uses them, by providing guarantees around the value itself.

Theres edge cases here especially with things like monotonic counters that will be nasty, including:

1. random resets back to 0 that occur due to some internal counter in the kernel resetting, or some value outside of this. SumObserver is still the right category of observer here, but you'll be violating it's constraint through no fall of your own.

In my experience these type of constraints can be handled on the consumer side, with functions or operations like nonNegativeDerivative which will show you the rate by which something is increasing.

[lzchen]

@toumorokoshi
Your analysis for the usefulness between SumObserver and UpDownSumObserver makes sense. There doesn't appear to be many differences functionality wise. I believe the SumObserver is better suited for rate calculations (as you've pointed out for monotonicity), as a pseudo "promise" that all values should be non-decreasing so some meaningful insight can be derived from the non-decreasing numbers, and rates can safely be calculated. As for the edge cases you've pointed out, I don't believe any type of instrument can handle those appropriately currently.

[codeboten]

LGTM, some non-blocking suggestions