[statsd] Disable statsd buffering by default

[sgnn7]

What does this PR do?

Due to impact on users of other clients where buffering was enabled by default, especially in environments and frameworks where fork() is used we will for the time being disable buffering by default until a decision is made on the path forward. Buffering can still be turned on with disable_buffering = False flag it's just that for now it is defaulted to True.

Description of the Change

• Use of DogStatsd via statsd module-level object defaults to synchronous (un-buffered) metric sending.
• Use of DogStatsd via the default constructor defaults to synchronous (un-buffered) metric sending.

Alternate Designs

In discussion (TBD). We may revert this and use automated ways to detect environments that are incompatible to thread-based buffering.

Possible Drawbacks

Lower performance in high-throughput environments.

Verification Process

Unit tests cover most of this:

python$(python --version 2>&1 | cut -c8-8)" -m unittest -vvv tests.unit.dogstatsd.test_statsd

Additional Notes

This change may be reversed in the future but for now, the risk is too high for user disruption.

Release Notes

Disable statsd buffering by default. Buffering can be enabled with disable_buffering = False flag.

Note: Since this is just a partial revert of https://github.com/DataDog/datadogpy/pull/670, removal of both release notes can be done as it's a net-0 change

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.

[sgnn7]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[therve]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).