Socket is not reinitialized when initialize is call after the first setup

[valerian-roche]

Describe the bug
If the initialize method is called after a first packet has been sent and the socket is still opened, then any change to host, port or socket_path will not have any impact until the socket is closed
If the socket is never closed, then changes are never reflected

To Reproduce
Steps to reproduce the behavior:

1. Drop packets for the default port (8125) or the port set through DD_DOGSTATSD_PORT environment variable
2. A bit of code calling statsd with the first port, and then calling initialize to change the port or switch to UDS
3. The socket is never switching to the new port (can be checked through lsof) and packets are sent to the black-hole of the firewall as setblocking(0) is set
4. The agent never receives any packet through the new port/socket

Expected behavior
Once initialize is called, ensure the old socket if opened is discarded and a new one is opened on demand with the new target peer

Screenshots
If applicable, add screenshots to help explain your problem.

Environment and Versions (please complete the following information):
Using datadogpy version 0.40.1 in python 2.7 (though I do not expect a different behavior in python 3.X)

Additional context
It is currently possible to work-around the issue by calling statsd.close_socket() after calling the initialize function, though it may be overkill if the target socket has not actually changed

[valerian-roche]

I will be raising a pull-request for this tomorrow. I need to figure out the issue with some fixtures I have in some tests

[github-actions]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.

If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of this project.

2. Comment that the issue is still reproducible and include updated details requested in the issue template.

[vickenty]

Fixed with #808 in 0.48.0