Add ability to disable statsd via new disable_statsd parameter in initialize

[carusology]

Closes #778.

Requirements for Contributing to this repository

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• The pull request must only fix one issue, or add one feature, at the time.
• The pull request must update the test suite to demonstrate the changed functionality.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

This merge request makes it possible to disable emitting statsd metrics when calling the initialize() function or Dogstatsd constructor instead of just the DD_DOGSTATSD_DISABLE environment variable.

I was inspired to make this change because I am working on project that uses Pydantic Settings to manage configuration settings - not just environment variables. This is a purer way to disable statsd with that dependency, as environment variables are only one of several ways to manage configuration. I noticed a similar concern from another engineer in #778.

Description of the Change

• This allows statsd emittance to be disabled via configuration managed beyond just environment variables (e.g. Pydantic Settings).
• It fixes the README so that it accurately describes the existing behavior of DD_DOGSTATSD_DISABLE and includes this new behavior.

Alternate Designs

No alternative designs were considered.

Possible Drawbacks

No obvious ones. This is a minor additive change to existing functionality.

Verification Process

I wrote unit tests to verify the new behavior via the constructor. I did not see a great way to write unit tests over this case when invoked via initialize().

Additional Notes

N/A

Release Notes

I think the PR description and CHANGELOG updates are self-sufficient.

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.

[carusology]

I can't seem to add a label? This should be tagged with changelog/Added

[carusology]

Hello @rayz 👋

It looks like you did the most recent release of this library. Do you happen to know how to get this in front of reviewers?

[carusology]

Hello @armcburney and @chouetz 👋

It looks like you two collaborated on the most recent pull request for this library. Do you happen to know how to get this in front of reviewers?

[chouetz]

Hello @armcburney and @chouetz 👋

It looks like you two collaborated on the most recent pull request for this library. Do you happen to know how to get this in front of reviewers?

Hi @carusology let me contact them for you, and thanks for your contribution.

[StephenWakely]

Hi, apologies but I don't think this option really makes sense here.

It isn't the responsibility of a library to disable itself and just adds complexity. It should be simple enough to create a wrapper over the library that only calls into it when needed.

Let me know if I am misunderstanding things.