Asynch Instruments: Spec Conformance

[hdost]

In an effort to get closer to the spec I was taking a look at the asynchronous instruments. There's an opportunity for a few different namings which might make more sense. I'd like to put it to
UpDownCounterObserver is now Asynchronous UpDownCounter
Sum Observer is now Aysynchronous Counter
ValueObserver is now Asynchronous Gauge

However even in the spec there is some different suggestions for names. Before I go down the route of making a big patch I'd like to discuss the naming. Personally I think the following would be the best names for the replacements (in order):

• <type>_asynchronous_up_down_counter
• <type>_asynchronous_counter
• <type>_asynchronous_gauge or <type>_gauge

Alternatives would be:

• <type>_observable_up_down_counter
• <type>_observable_counter
• <type>_observable_gauge or <type>_gauge

Obviously there would be CamelCase types associated, but these would be the meter methods.

Additionally, I've seen in some languages that their choosing to implement the asynchronous gauges as use gauges. In either case of the above mentioned there could be an possibility of using: <type>_gauge

[TommyCpp]

I think observable may be clearer as async/asynchronous is a very important concept in Rust and I don't want to people to confuse the async instrument as something that must be used in async runtime.

[jtescher]

Also a heads up that the metrics impl may need to be almost completely re-written as many parts of the design are not great and the spec has changed since the first impl. Been focusing on getting the trace side to 1.0 first, but feel free to get a head start looking at better options here 👍

[hdost]

I think observable may be clearer as async/asynchronous is a very important concept in Rust and I don't want to people to confuse the async instrument as something that must be used in async runtime.

Makes perfect sense to me.

What do you think of the gauge vs observable_gauge?