TCP listener for statsd input

[szibis]

Required for all PRs:

• CHANGELOG.md updated (we recommend not updating this until the PR has been approved by a maintainer)
• Sign CLA (if not already signed)
• README.md updated (if adding a new plugin)

This PR adds TCP listener based on tcp_listener input code. We need TCP listener for statsd input in cloud environment's where UDP balancing is not available and for more reliable communication.

This is missing feature that is supported in etsy statsd - https://github.com/etsy/statsd/blob/master/docs/server.md

[danielnelson]

As you mentioned this code is heavily based on the tcp_listener plugin, but that plugin was deprecated and replaced with socket_listener.

While it might be nicer if this was based on the newer socket_listener code, I think this might be quite a bit more work, as the existing statsd plugin is similar to the old udp_listener.

One concern I have is that I often see intermittent errors with the udp_listener when running unittests. Though looking through the github issues I don't see many reported issues. @phemmer Do you have a sense of if this code might be problematic due to being based on tcp_listener?

[danielnelson]

Remove this line, looks a leftover from a rebase.

[danielnelson]

I am assuming this is not part of the statsd protocol, any chance this will confuse a tcp statsd implementation? Maybe we should just close the connection?

[phemmer]

@phemmer Do you have a sense of if this code might be problematic due to being based on tcp_listener?

The only part of the tcp_listener plugin which I personally considered bad design was it dropping metrics. It's my stance that on stream protocols, the receiver should not drop any metrics if it cannot process them fast enough. The receiver should instead stop reading which the sender will then notice, and can handle as it sees fit.
Similarly when connection count maxes out, instead of accepting and closing, don't accept. Let the client's TCP timeouts handle it. That way if the count maxes out for just a brief moment, we don't unnecessarily deny a connection.

But neither of these is a major issue, so the code should be fine to use.

[danielnelson]

So, just need to discuss my code comments. In the future we can rebuild stastd input on socket_listener.

[szibis]

I can't do the work in next two weeks. After that no problem and I will fix all from comments and stay with tcp_listener (working on our prod from 3 months by now). Is this ok with 1.4.0 release plan ?

[danielnelson]

@szibis Cutoff for 1.4 features is currently around the 16th of August.

[szibis]

@danielnelson all comments fixed

[danielnelson]

This line is added twice and there is a merge conflict. Recently I have been adding the changelog updates separately to avoid these merge issues, so you can just remove all changes to this file.