Fix cc.requests.outstanding.gauge when using puma web server

[Samze]

https://github.com/cloudfoundry/cloud_controller_ng/issues/1312 introduced cc.requests.outstanding.gauge which holds the counter in memory. With the introduction of puma there may be multiple processes, so each would emit its own value for this metric. This would cause the gauge to flop between values. This metric is listed as an important kpi for capi scaling https://docs.cloudfoundry.org/running/managing-cf/scaling-cloud-controller.html#cloud_controller_ng.

This fix for puma will instead uses Redis for the gauge.

• Refactor requests_metric to use statsd_updater
• Statsd_updater now contains statsd requests logic
• Add Redis/Inmemory store to statsd_updager
• Add a missing mutex to counter for thread safety for the in memory implementation.
• Chose to prefix the entry in redis with metrics: but open to feedback here.

Inspired by https://github.com/cloudfoundry/cloud_controller_ng/commit/4539e596ab6ae64556b170e4387633e9ebd55292

An alternative considered, was to read the prometheus metric and re-emit that to StatsD, however we observed performance degradation. Presumably because of the number of reads from disk for the DirectFileStorage to aggregate the metric across processes and so Redis seemed the best approach.

cc @sethboyles / @pivotalgeorge

---

• [x] I have reviewed the contributing guide

• [x] I have viewed, signed, and submitted the Contributor License Agreement

• [x] I have made this pull request to the main branch

• [x] I have run all the unit tests using bundle exec rake

• [ ] I have run CF Acceptance Tests

[sethboyles]

Code looks good, I'll do acceptance tomorrow