[statsd] Add ability to toggle `statsd.disable_buffering` state during runtime

[sgnn7]

What does this PR do?

• Adds ability to set statsd_instance.disable_buffering flag after initialization
• Adds said flag as a argument to initialize() to be usable for the module-level statsd instance

Description of the Change

While not likely to be useful currently, if/when we enable buffering on the DogStatsd clients by default again we will want to have this feature already in place since the module level statsd may not behave as expected in fork()-based environments. Because datadog.initialize() cannot recreate the instance of the module-level statsd, we need a runtime setting for disable_buffering instead of recreating the instance, making the implementation somewhat constrained in how it is done.

As a side-effect, this change allow use of the module-level statsd instance with buffering enabled which was previously not possible.

Alternate Designs

None that would make sense with the limitations provided.

Possible Drawbacks

Assumptions were made in the logic that datadog.initialize() would be only called once for the application. While there are protections around concurrent invocations, there could be edge cases not covered if multiple concurrent calls to `initialize are made to change this flag or if the data is being added to the buffer while the buffering is being disabled.

Verification Process

Tests covers the underlying functionality of this feature but it can be tested with:

• Using either:
  • datadog.initialize() and setting statsd_disable_buffering flag
  • Instantiating DogStatsd
• Verifying that data flows through

Additional Notes

This feature will be gradually documented as it is expected to be useful only in very niche high-throughput cases.

Release Notes

• [statsd] Add ability to toggle statsd.disable_buffering state during runtime
• [datadog] Add ability to use statsd_disable_buffering as an argument to datadog.initialize()

Review checklist (to be filled by reviewers)

• [ ] Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
• [ ] PR title must be written as a CHANGELOG entry (see why)
• [ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• [ ] PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
• [ ] PR should not have do-not-merge/ label attached.
• [ ] If Applicable, issue must have kind/ and severity/ labels attached at least.

[therve]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).