[Bug] Filter indicators don't reflect filters applied in referenced/nested datasets

[rumbin]

Dashboard filters that only become effective in nested/references datasets, i.e., `select ... from {{ dataset(123) }}', are correctly applied in the query but are not reflected in the filter indicator.

How to reproduce the bug

1. Create a virtual dataset which applies some push-down filtering via filter_values('my_column')
2. Create another virtual dataset which selects from the previously created dataset and which does not contain this column my_column, neither as an output column nor via filter_values() evaluation.
3. Create a chart based on the second dataset and place it on a dashboard.
4. Add a filter on my_column to the dashboard-native filters.
5. Apply a filter on my_column on the dashboard.

Expected results

• The my_column filter is being injected into the chart's query.
• The filter indicator reflects that the my_column filter is being applied to the chart on our dashboard.

Actual results

• Good: The my_column filter is actually being injected into the chart's query.
• Bad: The filter indicator noes not reflect that the my_column filter is being applied to the chart on our dashboard.

Screenshots

Real-life example:

Filter indicator shows only a few filters applied:

The compiled/executed query confirms that all filters actually got injected

This is how we referenced the dataset:

And this is the relevant part of dataset(123):

Environment

(please complete the following information):

• browser type and version:
• superset version: 3.0.2
• python version: python --version
• node.js version: node -v
• any feature flags active:

Checklist

Make sure to follow these steps before submitting your issue - thank you!

• [x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
• [x] I have reproduced the issue with at least the latest released version of superset.
• [x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

Side note:
The where_column_in() Jinja function shown in the last screenshot is a NULL-safe custom function of ours. It should not have any influence on the reported issue, imho.

[rusackas]

I assume this is still happening in 4.0 (since we're dropping 3.0 support)? This is a bit of an edge case for most, I would assume, which is probably why it's quiet. PRs/investigation welcome, if you feel up to it, of course!