JMXTimer exposes attributes in inconsistent time units

JMXTimer objects are constructed with a duration time unit, which is fixed to MICROSECONDS in the codebase. According to that, we should expect the time values returned from the JXMTimer are in micros.

However, the time unit is inconsistent among the JMXTimer attributes.
Most of the attributes such as percentiles and mean values returned are in micros, except Values and RecentValues.
Those 2 attributes expose the raw histogram values of the underlying Timer (CodaHale) and the values are fixed to be based on nanos.

The inconsistency leads to confusion and mis-interpretation of the values, if the end user is not familiar with the implementation details. One may consider the Values and RecentValues are also in micros.
Besides the confusion, given the intention is to record the time values in the micros resolution, we do not need to allocate 165 buckets in the DecayingEstimatedHistogramReservoir. 165 buckets is necessary for nanos, but not for micros. We can only allocate 90 buckets and it should reduce ~50% memory footprint used by the Timers.

I'd like to propose an approach to scale the values being recorded in the reservoirs used by Timers and reduce the allocation.