fix: create permissions on DB import

[betodealmeida]

SUMMARY

A few bugs related to catalogs and permissions:

1. When a database is imported, catalog and schema permissions are not created. Ideally we should have the import functionality call the corresponding command (CreateDatabaseCommand in this case) to prevent duplicate logic (the import/export flow was created before the introduction of commands). For now this PR just adds the logic manually.
2. When a database is updated, datasets and charts are not having their catalog_perms updated.
3. Databricks has a weird behavior where get_default_catalog() ⊈ get_catalog_names(), so I fixed it.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

N/A

TESTING INSTRUCTIONS

Added and updated tests.

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

[Vitor-Avila]

Just to double check: if this version change were to affect any other tests or logic, it should fail the GH Actions for this PR as well, right?

[betodealmeida]

Ah, I need to revert this, it was for testing locally. Sorry.

[Vitor-Avila]

Hey @betodealmeida I believe this should be good to be approved as soon as you revert this change 🙌

[Vitor-Avila]

if SHOW CATALOGS returns only spark_catalog, it seems we're returning it. Do we want to return spark_catalog, or do we need to return hive_metastore instead (when there's only spark_catalog)? I'm asking it because I think there are issues with other metadata calls if we try to use spark_catalog when the catalog selected in the form is hive_metastore (or if UC is not enabled).

Also, if multi_catalog is disabled, do we want to rely on SHOW CATALOGS? Should we validate if multi_catalog is disabled first, and if so return the value of current_catalog() directly (which should be the catalog from the form)?

[betodealmeida]

The problem is that we need to create the permissions regardless of the state of multi_catalog. For Databricks, the migration process will create permissions for:

1. Whatever get_default_catalog() returns.
2. All the catalogs from get_catalog_names different from the default catalog from (1).

For Databricks, this means we're creating 2 permissions when Unity Catalog is not enabled:

1. [Databricks].[hive_metastore]
2. [Databricks].[spark_catalog]

This in itself is already a problem for the admin — which would should they assign roles to? Either one is problematic, depending on the status of multi_catalog:

With multi_catalog disabled the catalog sent by API calls is null, so it gets replaced with the default catalog, hive_metastore. If the admin assign roles to [Databricks].[spark_catalog] people won't be able to access datasets, because of the name mismatch.

With multi_catalog enabled the only option in the dropdown is spark_catalog. Which means if the admin assigned roles to [Databricks].[hive_metastore] people won't be able to access datasets.

With the change in this PR, everything is consistent, because the default catalog is part of the list of catalogs.

[sadpandajoe]

@supersetbot label 4.1