add ns and us for config duration units

[SylvainJuge]

When using autoconfiguration SPI, configuration options can be parsed as a java.time.Duration by using ConfigProperties#getDuration.

However, the nanoseconds and microseconds are not supported, the smallest unit we can use is milliseconds (which is also the default).

This PR adds support for both nanoseconds ns and microseconds us.

Also, this adds a test to ensure using a negative duration can be used as a way to mark a configuration option as disabled (no change in implementation needed though).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.05%. Comparing base (3e8092d) to head (02a0a12).
Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6654      +/-   ##
============================================
- Coverage     90.05%   90.05%   -0.01%     
- Complexity     6276     6278       +2     
============================================
  Files           697      697              
  Lines         18949    18951       +2     
  Branches       1858     1858              
============================================
+ Hits          17065    17066       +1     
  Misses         1312     1312              
- Partials        572      573       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jack-berg]

Seems reasonable. Out of curiosity, what's the motivation? Which properties are you trying to configure to this level of granularity?

[SylvainJuge]

Seems reasonable. Out of curiosity, what's the motivation? Which properties are you trying to configure to this level of granularity?

For the span stacktrace we need to define a otel.span.stacktrace.min.duration configuration option to configure it. When updating the tests in the implementation PR open-telemetry/opentelemetry-java-contrib#1414 we used to test with very short spans like 1ns and using the Duration parsing feature did not allow for such short durations.

In the mean time I've updated the tests in the PR to use milliseconds as the feature does not require such short durations, however there should not be any limitation on the configuration options.

In practice for this span stacktrace feature, I don't expect end-users to use nanosecond granularity, however having the ability to configure it with less than a millisecond would be relevant for example to help identify what triggers very short-lived spans like a call to an in-memory cache which can be less than a millisecond.