Add metric for per-response-type duration

[dannysauer]

It's sometimes useful to know response time separated out by status code. Add another histogram for that.

I think it makes a little more sense as a subgroup under request.status.xxx.duration, but I'm also ok with request.duration.status.xxxx if someone has a strong opinion.

Resolves #2587

[dannysauer]

Force-push adds a test case and adds my name to THANKS, per the commit guide (even though I'm not sure a 1-line contribution really warrants that 🤷)

Test case should presumably go back to succeeding once #2581 is merged, I guess. The statsd change in here passes the relevant tests just fine. :)

[judgeaxl]

I'd like to argue that this should be an optional feature, or be changed to use tags for the response code. Tags would give much better flexibility while only requiring a single metric. I understand not all stats collectors support tags, but I'd still rather have the tags when they are supported, than individual metrics.

[dannysauer]

It's a fine argument to make, but I don't see tag support in this code's implementation of the statsd protocol. So that seems unlikely to happen. :)

If the code was hypothetically to be converted to use the Python Statsd library, there's also an argument made there against tags: https://statsd.readthedocs.io/en/v3.2.1/tags.html. So that would still likely be a bit of an uphill battle.

[judgeaxl]

Yeah, it's a bit sad that statsd don't support tags. I'm using the extensions from Datadog where tags are the key to getting the most out of pretty much anything. Thus I see why the individual metrics would be useful. My ask is really more that one gets the option of generating specific metrics or applying them as tags.

[dannysauer]

Issue was closed because apparantly some undocumented change planned for somewhere will make this obsolete someday? 🤷‍♂️