[SDTEST-482] Add get_time_provider setting to avoid timecop mocking the clock_gettime

[anmarchenko]

What does this PR do?
Adds get_time_provider setting similar to time_now_provider that provides a workaround for the situation when timecop mocks Process.clock_gettime.

Motivation:
Timecop v0.9.9 allows to mock monotonic clock, which might affect tests tracing. See the example of this failure here.

How to test the change?
Unit tests are provided

[TonyCTHsu]

Is this an internal usage from CI gem? Perhaps we should avoid making it public

[anmarchenko]

@TonyCTHsu the option to set Time.now provider is public and documented for customers here:
https://github.com/DataDog/dd-trace-rb/blob/master/docs/GettingStarted.md#setting-the-time-provider

In this case, I see no reason to hide this option from public usage: there are customers that used time_now_provider, so they could use get_time_provider as well

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.85%. Comparing base (2209a7c) to head (b03599c).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3948   +/-   ##
=======================================
  Coverage   97.85%   97.85%           
=======================================
  Files        1303     1303           
  Lines       78139    78200   +61     
  Branches     3894     3895    +1     
=======================================
+ Hits        76461    76521   +60     
- Misses       1678     1679    +1     

Flag	Coverage Δ
	97.85% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-09-25 13:24:52

Comparing candidate commit b03599c in PR branch anmarchenko/get_monotonic_time_provider with baseline commit 2209a7c in branch master.

Found 1 performance improvements and 0 performance regressions! Performance is the same for 22 metrics, 2 unstable metrics.

scenario:tracing - Propagation - Datadog

• 🟩 throughput [+3265.872op/s; +3365.861op/s] or [+10.812%; +11.143%]

[ivoanjo]

time_now_provider was added in #1224 . I guess the intent was to allow better control over span start/end times?

[anmarchenko]

As agreed with @TonyCTHsu, we will refrain from documenting this option as of now because we don't currently see any use case for it outside of datadog-ci gem (where it will be configured automatically when timecop is detected when running tests).

[delner]

I like the idea of configuring in a cooperative way over forcing a mock. My question is more about the name.

time_provider suggests that all time in the library will be provided through this provider? Do we have a means of really enforcing this consistent use? If we use Time.now somewhere instead of this provider, we may end up with broken expectations around behavior.

Off the top of my head, I feel like this could be either:

1. Commit to using this more broadly
2. OR rename this to trace_time_provider and more narrowly bound its use. But then it doesn't belong in Core.

WDYT? (I'm not quite sure what to do about this.)

[anmarchenko]

@delner I don't have any preference on this topic, so I think whatever works for tracing/core is fine for me

[p-datadog]

Diff LGTM, I do not have an opinion on the naming/scope.

[anmarchenko]

@delner I suggest let's merge it now because it solves a problem for the users, I will leave the question of whether it belongs to Core or Tracing open for now