stats: make it's possible to enable the new stats API

[wbpcode]

Commit Message: stats: make it's possible to enable the new stats API
Additional Description:

The PR did two things:

1. used the stats_tags and use_all_default_tags to infer whether the new tag-friendly API should be used or not.
2. merged the ScopImpl and TagScopeImpl into single class and use a bool flag to tell legacy code or new logic should be used. This is because we cannot get the stats_tags and use_all_default_tags when we constructing the ThreadLocalStore and the root scope. So, we need to ensure the a single scope implementation could support both legacy and new logic.

The new tag-friendly API will be enabled when: no custom stats_tags and use_all_default_tags is true.

NOTE: We still add a new runtime flag. This runtime flag is used to guard existing behavior in the process of migrating the existing stats API calling to use the new API. We need lots of changes to migrate and ensure all default tags could be emitted correctly by the new API. Before complete the migration, the runtime guard is necessary.

Risk Level: low.
Testing: unit.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.

[repokitteh-read-only]

CC @envoyproxy/runtime-guard-changes: FYI only for changes made to (source/common/runtime/runtime_features.cc).

🐱

Caused by: #45846 was opened by wbpcode.

see: more, trace.

[wbpcode]

/gemini review

[gemini-code-assist]

Code Review

This pull request implements the explicit-tags logic for the stats store, allowing scope-level tags to propagate to every stat without re-parsing flat names, controlled by the runtime guard envoy.reloadable_features.enable_stats_explicit_tags. The review feedback identifies a critical memory corruption issue in legacy mode where populateList is called with empty arguments, resulting in an incorrectly sized StatNameList. Additionally, suggestions are made to add safety assertions in SymbolTable::populateList and to use auto for type deduction when creating a shared pointer.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

In legacy mode, calling the 4-argument populateList with empty base_name and name_tags results in a corrupted StatNameList because stat_name_count is set to 2, but only 1 element's bytes are written. When the list is cleared in the destructor, it will iterate 2 times, reading out-of-bounds garbage bytes for the second element and calling symbol_table.free on them, which can cause memory corruption or crashes.

Since we only need to store a single prefix in legacy mode, we should use the 3-argument populateList overload instead, which correctly populates the list with exactly 1 element.

Suggested change

	parent_.alloc_.symbolTable().populateList(prefix, {}, {}, prefix_list_);
	parent_.alloc_.symbolTable().populateList(&prefix, 1, prefix_list_);

[wbpcode]

the populate list could handle empty stat name correctly. The empty stat name also has one byte.

[gemini-code-assist]

To prevent silent corruption of StatNameList when empty StatNames are passed, we should add assertions to ensure that tagged_name, base_name, and all tags in name_tags are not empty.

void SymbolTable::populateList(StatName tagged_name, StatName base_name, StatNameTagSpan name_tags,
                               StatNameList& list) {
  ASSERT(!tagged_name.empty());
  ASSERT(!base_name.empty());
  for (const auto& tag : name_tags) {
    ASSERT(!tag.first.empty());
    ASSERT(!tag.second.empty());
  }

  const size_t stat_name_count = name_tags.size() * 2 + 2;

[wbpcode]

the populate list could handle empty stat name correctly. The empty stat name also has one byte.

[gemini-code-assist]

According to the general rules, we should prefer using auto for variable declarations when the type is clearly deduced from the right-hand side (e.g., when using std::make_shared or std::make_unique).

Suggested change

	std::shared_ptr<ScopeImpl> new_scope = std::make_shared<ScopeImpl>(
	auto new_scope = std::make_shared<ScopeImpl>(

References

1. Use 'auto' for variable declarations when the type is clearly deduced from the right-hand side (e.g., when using 'std::make_shared' or 'std::make_unique'), as explicit types in these cases are considered redundant and noisy.