feat(dashboards): Add config to filter implicit tags in list API

[Antonio-RiveroMartnez]

SUMMARY

Noticed our Dashboard List API is returning ALL the implicit tags in the List endpoint, which is damaging the performance of such API. These tags are pure metadata, and not used for any security process in our app, what's more, even the UI is filtering those and only rendering custom ones.

This PR introduces a new config that by default respect the current behavior so nothing gets changed inadvertently, this new config will make FAB filter at the JOIN level which tags to include as part of the response. This new config is read by a new Mixin added to the DashboardRestApi.

What it does? It creates a new relationship called custom_tags that is the one filtering by tag type = custom at the JOIN level, and only uses this relationship when the new config is True, it leverages the fact that FAB uses list_columns to create those joins automatically. On the frontend, the change is transparent as the custom_tags get transformed to tags on those list endpoints using the mixin.

Why a config and not a Feature Flag? The relationship is created at the model and manipulating the model is not something you can do at runtime (request), so that's why I'm using a config.

Why at the JOIN level? Because filtering at python level with for example a callable would not help on query performance, only on response size.

Why a Mixin? We could consider reusing this mixin on other parts where tags are returned by default like ChartRestApi etc later on.

Does this affect current functionality? No, the UI works exactly the same as before, you can list resources and see the tags associated with them, you can edit tags, you can filter content by tag etc.

At some point we would like to evaluate how to get rid of those implicit tag altogether in these APIs, but that major effort would be out of the scope of this initial optimization.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Default behavior without filtering:

When the config is enabled:

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags: TAGGING_SYSTEM
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

❌ Patch coverage is 72.00000% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.15%. Comparing base (ab8352e) to head (94236df).
⚠️ Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
superset/views/custom_tags_api_mixin.py	55.17%	10 Missing and 3 partials ⚠️
superset/dashboards/schemas.py	66.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #36246       +/-   ##
===========================================
+ Coverage        0   68.15%   +68.15%     
===========================================
  Files           0      633      +633     
  Lines           0    46512    +46512     
  Branches        0     5043     +5043     
===========================================
+ Hits            0    31698    +31698     
- Misses          0    13547    +13547     
- Partials        0     1267     +1267     

Flag	Coverage Δ
hive	43.79% <56.00%> (?)
mysql	67.24% <72.00%> (?)
postgres	67.29% <72.00%> (?)
presto	47.39% <56.00%> (?)
python	68.11% <72.00%> (?)
sqlite	66.91% <72.00%> (?)
unit	100.00% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dpgaspar]

LGTM. We should definitely filter out non custom tags as the default behaviour.

Is it still possible to get into the 6.X breaking change collection with something like that @sadpandajoe ?