Allow reporting StatsD metrics over UDS sockets

[larribas]

This is a follow-up PR to #2067

It allows gunicorn users to specify a UDS address leveraging the statsd_host config option, and reporting metrics through a socket.

I've tried to touch the fewest things possible, added a couple of tests and done a manual test you can reproduce like this:

datadog.yml:

use_dogstatsd: true
dogstatsd_port: 8125
bind_host: '127.0.0.1'
dogstatsd_non_local_traffic: true
dogstatsd_socket: '/var/run/datadog/dsd.socket'

docker-compose.yml:

version: '3.7'
services:
  gunicorn:
    image: python:3.8-slim
    command:
      - python 
      - /app/gunicorn/app/wsgiapp.py 
      - --bind=0.0.0.0
      - --statsd-prefix=test.gunicorn
      - --statsd-host=unix:/var/run/datadog/dsd.socket
      - test:app
    working_dir: "/app/examples"
    environment:
      PYTHONPATH: "/app"
    ports:
      - "8000:8000"
    networks:
      - default
    volumes:
      - .:/app
      - datadog:/var/run/datadog/
    depends_on:
      - datadog

  datadog:
    image: datadog/agent:6.13.0
    environment:
      DD_API_KEY: <a_valid_dd_api_key>
    volumes:
      - ./datadog.yml:/etc/datadog-agent/datadog.yaml
      - datadog:/var/run/datadog/
    networks:
      - default

networks:
  default:

volumes:
  datadog:

Manual test steps:

• Run docker-compose up
• Go to localhost:8000 several times
• Verify the metrics test.gunicorn.* appear in your datadog account
• Change to --statsd-host=datadog or --statsd-host=datadog:8125 and repeat the steps

[larribas]

There is a backwards incompatible change in this PR, where people who were specifying something like --statsd-host=unix:9999 would see that parsed as a unix socket and fail.

For the sake of backwards compatibility, we shouldn't change the behavior of utils.parse_address() either, so I'm going to do this defensively inside of the config.validate_address() function.

Edit: Solved

[larribas]

@benoitc @wmalinowski any chance to merge this one? :pray:

[RafaAguilar]

A year and a half and this keep been a relevant feature, any updates on merging this @wmalinowski @benoitc ?

[benoitc]

thanks for the PR! (sorry for the delay)