fix: remove old constraint

[betodealmeida]

SUMMARY

The dataset model has a comment that says:

superset/superset/connectors/sqla/models.py

Lines 1135 to 1144 in 9487d6c

	# Note this uniqueness constraint is not part of the physical schema, i.e., it does
	# not exist in the migrations, but is required by `import_from_dict` to ensure the
	# correct filters are applied in order to identify uniqueness.
	#
	# The reason it does not physically exist is MySQL, PostgreSQL, etc. have a
	# different interpretation of uniqueness when it comes to NULL which is problematic
	# given the schema is optional.
	__table_args__ = (
	UniqueConstraint("database_id", "catalog", "schema", "table_name"),
	)

But turns out there is an old migration from 2016 that adds the uniqueness constraint to the schema:

superset/superset/migrations/versions/2016-04-15_08-31_b4456560d4f3_change_table_unique_constraint.py

Lines 36 to 38 in 9487d6c

	op.create_unique_constraint(
	"_customer_location_uc", "tables", ["database_id", "schema", "table_name"]
	)

With the introduction of catalogs in SIP-95 this constraint needs to either be updated to include catalog, or removed to align with the SqlaTable model. In this PR I went with the latter.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

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

[mistercrunch]

Hey, thinking about applying some of the ideas in #29546, which would point towards either accumulating this PR and holding it until next release, or merging this in to a no-op place that we would bring into an actual migration later.

Curious as to whether you all think it's better to hold the PR, or to merge into a temporary place.

[mistercrunch]

Easiest option here seems like it'd be to add a hold:next-major:migration label (or similar) and defer

[betodealmeida]

Tagged this for 5.0.