I'd like to explore ways to prevent tag extracted name collisions in Envoy since there have been multiple issues brought up wrt that (see #2683 and #2141)

Description: I want to start by defining a collision in this context. Stats in Envoy are created with a single string. Multiple strings can map to the same tag extracted name when the stats are logically similar (only differ by tag values). This is expected. However, it is also assumed that all strings that map to the same tag extracted name have had the same named tags extracted from it - not the same tag values, but the same tag names. The issues above come up when this assumption breaks down because there are currently no checks to ensure the latter isn't violated. Pulling an example from #2683:

http.<stat_prefix>.fault.aborts_injected and http.<stat_prefix>.fault.<downstream-cluster>.aborts_injected both resolve to http.fault.aborts_injected. These are logically different stats because one represents the total of some metric and the other represents some slice of that metric. The same metric with the same name (tag extracted name in Envoy) and different tag values (in a tagged system) is, in my experience, used to represent a completely disjoint slice of the metric's space with no overlap with other stats with a different tag combination. Given that setup, this sort of collision seems undesirable.

As @mattklein123 mentioned in #2683 this is somewhat difficult to check this since statsd can be created anywhere and they are "keyed" in Envoy caches by their full string name, which won't prevent collisions relating to the tag-extracted name. A rough solution could look like adding a second map (next to the existing TLS cache) that maps a particular tag-extracted name to some sort of hash of the list of tag names for that tag extracted name (or could be approximated by just the number of tags). That would, however, add some complexity and overhead to the stat allocation process. What are others' thoughts on this?