feat!: Change type of DD_TRACE_RATE_LIMIT to int

[zacharycmontoya]

Description

Changes the type of the DD_TRACE_RATE_LIMIT input to int (previously double)

Motivation

This aligns the cpp tracer behavior for DD_TRACE_RATE_LIMIT with the expected behavior of all the tracers in our Config Consistency initiative, such that only integer values are used.

Additional Notes

This may be unnecessary as we may be able to standardize our documentation that only integer values are accepted (what even is 0.1 of a trace?) and in doing so we are still compatible because integers on the command line can still be interpreted as a double. However, it could be good to do this in the type system just to be more specific. Thoughts?

Jira ticket: APMAPI-511

[dgoffredo]

what even is 0.1 of a trace?

0.1 traces in a second is 1 trace in 10 seconds. DD_TRACE_RATE_LIMIT has units of "traces per second," not "traces."

Possibly best to make it an integer for consistency's sake, but I did make sure that the existing Limiter implementation could handle values smaller than 1.

[zacharycmontoya]

what even is 0.1 of a trace?

0.1 traces in a second is 1 trace in 10 seconds. DD_TRACE_RATE_LIMIT has units of "traces per second," not "traces."

Possibly best to make it an integer for consistency's sake, but I did make sure that the existing Limiter implementation could handle values smaller than 1.

Ah you're right since it's traces per second it makes sense why this was implemented as a double earlier. It seems that the remaining languages only use integer values so there's a strong motivation to align. Thanks for clearing that up @dgoffredo 😄

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-10-04 00:07:10

Comparing candidate commit c7ce9e3 in PR branch zach.montoya/config-consistency/rate-limit-int with baseline commit f682d03 in branch zach.montoya/config-consistency/rate-limit.

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