feat(dbview): Add token request button to DuckDB and MotherDuck database modal

[guenp]

SUMMARY

• Add a DuckDBParametersSchema to break out the DuckDB connection URI into database, access token (for MotherDuck) and query
• Add a button to go to MotherDuck and copy an access token to paste directly into Superset.

The latter is implemented by adding support for the metadata description and load_default values from the parameters schema fields.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:

After:

TESTING INSTRUCTIONS

See animated GIF.

ADDITIONAL INFORMATION

• [ ] Has associated issue:
• [ ] Required feature flags:
• [x] 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
• [x] Introduces new feature or API
• [ ] Removes existing feature or API

[michael-s-molina]

@guenp @betodealmeida What's our policy for this screen regarding specific database configs? I thought this was a generic database interface given that it would be really difficult to maintain this modal if we add UI-specific elements for each database type which seems the case here. Are we planning to support specific versions of this modal for each database type?

[betodealmeida]

@guenp @betodealmeida What's our policy for this screen regarding specific database configs? I thought this was a generic database interface given that it would be really difficult to maintain this modal if we add UI-specific elements for each database type which seems the case here. Are we planning to support specific versions of this modal for each database type?

@michael-s-molina the frontend components are mostly generic, and the configuration lives in the DB engine spec (eg, https://github.com/apache/superset/pull/27908/files#diff-651962bab25f2e142c7d1701b15bed4e3c055374d855f1340b85724b573966b7R116-R129). In this PR they're adding some optional parameters to show the URL to get the token, which is useful in general, IMHO.

That being said, I actually think that the frontend components should be more specific. I think we should have a MotherDuckDatabaseConfig component, a BigQueryDatabaseConfig, and so on. The current approach of building a UI based on generic components that are shared between databases doesn't scale, and as you mentioned, and the databases will start stepping on each other toes very quickly.

[michael-s-molina]

That being said, I actually think that the frontend components should be more specific. I think we should have a MotherDuckDatabaseConfig component, a BigQueryDatabaseConfig, and so on. The current approach of building a UI based on generic components that are shared between databases doesn't scale, and as you mentioned, and the databases will start stepping on each other toes very quickly.

That was exactly my thinking. It's not a blocker for this PR but something we should consider given the flexibility we'll gain. It's similar to database engine specs where you have common elements but can also extend them to include specific things that will improve overall UX for users.