fix: filters panel broken due to tabs scroll

[justinpark]

SUMMARY

Fixes #30058

The EChart tooltip is hidden using visibility: hidden with opacity: 0 after it disappears, which causes tooltips generated from the previous tab to be recognized as scroll items when configuring the layout for the next tab, resulting in unnecessary scrollbars.

display:none means that the tag in question will not appear on the page at all (although you can still interact with it through the dom). There will be no space allocated for it between the other tags.

visibility:hidden means that unlike display:none, the tag is not visible, but space is allocated for it on the page. The tag is rendered, it just isn't seen on the page.

This commit addresses the issue by using a CSS hack to change the visibility hidden tooltip to display: none, effectively removing it and resolving the scrollbar problem.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:

before--css-hide-hack.mov

After:

after--css-hide-hack.mov

TESTING INSTRUCTIONS

1. Create a dashboard with 2 inner tabs
2. In one tab, add a bunch of charts so that it needs scrolling
3. In the other tab, add a few charts so it does not need scrolling
4. Create a native filter
5. Scroll to the bottom on the first tab and mouse over a chart to show a tooltip
6. Select the second tab
7. Check that the dashboard height is not calculated correctly and presents a scroll
8. Scroll to the bottom and see the native filters panel break

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• 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

[justinpark]

@michael-s-molina I also confirmed that this bug exists in 4.0 as well.

[rusackas]

Couple of options if you want to optimize further:

1. we can probably narrow this from Superset global to being part of the ECharts plugin(s), perhaps using Emotion Globals.
2. This might be a good excuse to open a PR on ECharts and fix it at the root ;)

Either way, I don't see this as a blocker for now. Things are lookin' good!

[justinpark]

Approach 2 is, of course, the fundamental solution, but I decided to leave it as a long-term solution considering the time gap involved in merging the patch and testing Superset compatibility with the corresponding version. (I plan to propose a related PR to echart later.)
Initially, I considered Approach 1, but I had concerns that adding a dependency on @emotion/react to the plugins' npm package might open the possibility for other custom plugins to apply custom global CSS. Therefore, I opted for this approach.

[rusackas]

LGTM... we can probably get fancy with how/where we do this, but this works well for today!