Draft of upstream specific stats on cluster

[FAYiEKcbD0XFqF2QK2E4viAHg8rMm2VbjYKdjTg]

Approach:

• Add a new proto field for a list of strings to represent upstream-specific classes to register on clusterInfo. For a Redis cluster, you might want to add redis_command_stats, for example.
• At clusterInfo initialization time construct the upstream-specific classes as needed, avoiding the need for lazy loading/locking at client/request time
• Simpler client/filter code; no need to pass stats down through the filer- just check if the desired class is present in the clusterInfo; if not do nothing.

General questions:

• How do you feel about the M downstream x N upstream issue? Does the multiple cluster per listener issue seem important enough to do this?
• Does my approach seem appropriate? Is there a better approach to adding information to a cluster that doesn't involve using a lock during runtime? I would love to register RedisCommandStats on a cluster at Redis filter init time, but the clusters can be initialized before the filter.

Unfortunately I see some weird behavior in client_impl_test with histogram stats. I'm not sure if it's an issue with my code ie additions to cluster mock, or if I am misunderstanding how to test that histograms are fired:

• The first test CommandStatsDisabledSingleRequest has an expectation for the aggregate timer via deliverHistogramToSinks(...), and the test passes whether the expectation is commented out or not.
• The second test CommandStatsEnabledTwoRequests has both the aggregate timer and the per command timer- but these both fail the expectation.
• The counter stats appear to work fine and the tests fail if I change the values.

Limitations:

• Changes only focus on getting client_impl_test.cc running and adding the new field
• The stats don't have the upstream + downstream name in them
• Did not remove enable command stats boolean- realistically the aggregate upstream request timer would be wrapped into the regular redis upstream stats, which would be ported over to the new style stats in a RedisGeneralStats class or something like that.
• Memory leak somewhere

Running tests:
$ bazel test -c dbg //test/extensions/filters/network/common/redis:client_impl_test --cache_test_results=no --test_output=all --test_filter=*CommandStats*