Move the code from the `init()` function of `dogstatsd/listerner` package to a named function

[GustavoCaso]

What does this PR do?

move init() functions content from the comp/dogstatsd/listeners package to a named function.

Motivation

This PR attempts to refactor the code to avoid using init() for the listeners package.

There is an existing function, newListenerTelemetry handles the creation of expvars and telemetry metrics and the functionality of updating those. It is only used for the NamedPipe listener in Windows. The UDP listener can use it as well.

I moved the newListenerTelemetry to the telemetry.go file available for all builds. I updated the UDP listeners to use it.

Unfortunately, we can not use newListenerTelemetry for the UDS listener as more variables need to be updated. I created the udsTelemetry struct and extracted all the logic for updating the telemetry into that struct. I decided to do it this way to validate that we like this approach. Maybe we can evolve listenerTelemetry to accept more custom logic in the future, but I thought it is good to keep it like this.

Additional Notes

• Should we rename the listenerTelemetry struct to namedPipeTelemetry?
• I did not see any testing around the telemetry part of the listeners. Is this something that we are aware? Should I invest time in adding testing?

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

We need to have the agent and the dogstastd processes running We need to send some metrics to the dogstatsd server so the listeners update the telemetry metrics

After sending information, if we fetch the agent process status with agent status we should see information about the dogstatsd changing.

Reviewer's Checklist

• [ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• [ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
• [ ] A release note has been added or the changelog/no-changelog label has been applied.
• [ ] Changed code has automated tests for its functionality.
• [ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
• [ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
• [ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
• [ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
• [ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
• [ ] If applicable, the config template has been updated.