[v0/v1 migration] FilterStatVarsByEntity migration

[nick-nlb]

Issue

b/513324218

Description

The api/stats/stat-var-search was broken under the following circumstances:

• VAI was enabled
• BT was not in use
• Entities were passed into the payload (these are used to filter the results from VAI.

No results were returned in these circumstances (whereas results were successfully filtered by sv/entity observation existence and returned when using BT).

The reason for this was that FilterStatVarsByEntity had not been migrated and was relying on the existence of the BT cache.

This PR creates a v3 (and diverted v2) implementation of the FilterStatVarsByEntity.

Testing

The problem is immediately visible on the dev scatter tool.

You can replicate it by:

• opening up the hierarchy without choosing a place and searching for "farms"
• the search will work (bring up results) as no filtering is occurring.
• delete the search from the search bar
• select United States as a place and "Counties" as the breakdown contained place.
• once again, search for "farms"
• you will now get no results.

Performing the same steps on production will give you a list of farm related stat vars that have been filtered to show only ones relevant to the place chosen.

Local Testing

To replicate the scenario we see in dev, you can start mixer with:

./run_server.sh \
    --feature_flags_path=$PWD/deploy/featureflags/local.yaml \
    --spanner_graph_info="$(cat deploy/storage/spanner_graph_info.yaml)" \
    --use_spanner_graph=true \
    --use_base_bigtable=false

The key flag is use_base_bigtable. By setting it to false, we disable BT, and in fact, we should be doing all our local testing this way if we want to truly test a Spanner only environment.

With big table set to false, in master you will see the same error as in dev. In this branch, you will see filtered results that should be identical to those found in production.

[gemini-code-assist]

Code Review

This pull request implements the FilterStatVarsByEntity method across the server architecture, including updates to the DataSource interface, dispatcher, and V2/V3 handlers. Specific implementations were added for Spanner, remote clients, and SQL data sources, supported by new unit tests and golden files. Review feedback suggests refining the response merging logic in DataSources to prevent potential nil pointer dereferences and optimizing the Spanner implementation with an early return when the input variable list is empty to avoid unnecessary database queries.

[clincoln8]

Thanks Nick, this is beautifully done!

Just a small nit to add some error logging. Mixer has been historically lacking in helpful logging/debugging traces, so we're trying to push for more observability in general (of course where reasonable).

[clincoln8]

nit: consider logging an error here before returning

[clincoln8]

nit: either log an error here or ensure that that lower level method CheckVariableExistence has adequate logging.