feat(sqllab): Adds refresh button to table metadata in SQL Lab

[Usiel]

SUMMARY

When table metadata changes (e.g. due to queries launched in Superset or other external changes) the user has no convenient way to force a refresh of the data for their TabState. The metadata is persisted even across sessions and will never update if the user stays on the current tab.

This feature is a first step to make this experience better by adding a refresh button for each table that allows a manual refresh.

Future improvements:

• Automatically refresh when query is likely to change the metadata
• Refresh metadata from time to time
• Do not persist the metadata for a SQL Lab tab forever: Maybe remove TableSchema and instead use a shared cache with well defined expiry

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

1. Load SQL Lab and expand a table
2. Change the table (e.g. add column)
3. Click refresh button
4. Expected: New column appears
5. Refresh the whole page
6. Expected: Column is still there (asserts the server-side TableSchema was properly updated)

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

[Usiel]

Rebased on master (thought I branched off the latest but apparently that was not the case)

[Usiel]

Having a guaranteed unique id would be better. From what I can tell we would need to return it from the API though, so I just went with the name for now.

[mistercrunch]

what is result.name in this context? Is it a fully-qualified table name? Regardless I think at this time changing anything in the table selector flushes the metadata section, so even just a table name should be safe for now. If we were to support tables from multiple schemas to remain accessible in this metadata section, this could in theory create some collision.

[Usiel]

It's just the table name, no extra qualifier like schema. And I see it the same way regarding collisions, so I'm good leaving it as is it.

[mistercrunch]

haven't dug deep, but I'd assume switching the name here we'd also change some other reference to it somewhere else in the method?

[Usiel]

We are destructuring isFetching (which is already part of the return of useTableMetadataQuery) into isMetadataLoading.
(isLoading is only true on the first load while isFetching is also true on subsequent fetches.)

I renamed the local variable isMetadataLoading to isMetadataFetching to be in sync with the naming convention.