chore(connector): Cleanup base models and views according to SIP-92

[john-bodley]

SUMMARY

This PR is a partial step towards SIP-92 Proposal for restructuring the Python code base where the superset.connectors submodule represents a bygone error of Superset when we supported both the Druid NoSQL and SQLAlchemy database engine connectors. Note long term the superset.connectors submodule should be abandoned with the models, views, and utilities moved elsewhere, but I thought it would be prudent to make said change in smaller bites.

Many of the base models and views are superfluous as they're only extended by one and only class. This PR:

1. Integrates the BaseColumn and BaseMetric classes into the TableColumn and SqlMetric classes respectively.
2. Integrates the DatasourceModelView class into the TableModelView class.
3. Moves superset.connectors.base.models.BaseDatasource to superset.connectors.sqla.models.BaseDatasource.

Ideally I would love to deprecate the BaseDatasource however at this stage I'm not brave enough. Currently (in addition to SqlaTable class) the AnnotationDatasource class is derived from it and thus sunsetting it is somewhat problematic. We maybe need to remove the AnnotationDatasource class somewhat like the Query class which behaves somewhat like a datasource/dataset.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

CI.

ADDITIONAL INFORMATION

• Has associated issue: [SIP-92] Proposal for restructuring the Python code base #20630
• 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

[codecov]

Codecov Report

Merging #24773 (53f8988) into master (abb8e28) will increase coverage by 1.69%.
The diff coverage is 87.80%.

❗ Current head 53f8988 differs from pull request most recent head 42e2c6c. Consider uploading reports for the commit 42e2c6c to get more accurate results

@@            Coverage Diff             @@
##           master   #24773      +/-   ##
==========================================
+ Coverage   67.23%   68.92%   +1.69%     
==========================================
  Files        1902     1900       -2     
  Lines       73939    73835     -104     
  Branches     8176     8176              
==========================================
+ Hits        49713    50894    +1181     
+ Misses      22113    20828    -1285     
  Partials     2113     2113              

Flag	Coverage Δ
hive	54.08% <61.58%> (-0.06%)	⬇️
mysql	79.18% <87.80%> (+<0.01%)	⬆️
postgres	79.28% <87.80%> (+<0.01%)	⬆️
presto	53.98% <61.58%> (-0.06%)	⬇️
python	83.35% <87.80%> (+3.58%)	⬆️
sqlite	77.85% <87.80%> (+<0.01%)	⬆️
unit	54.92% <52.74%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
superset/charts/post_processing.py	93.23% <0.00%> (+81.20%)	⬆️
superset/commands/utils.py	97.29% <0.00%> (ø)
superset/common/query_context.py	95.00% <0.00%> (ø)
superset/common/query_context_factory.py	76.81% <0.00%> (ø)
superset/common/query_object.py	95.97% <0.00%> (+2.51%)	⬆️
superset/common/query_object_factory.py	91.89% <0.00%> (ø)
superset/daos/chart.py	92.72% <0.00%> (ø)
superset/models/slice.py	87.62% <0.00%> (ø)
superset/security/manager.py	94.08% <0.00%> (+0.13%)	⬆️
superset/viz.py	64.51% <0.00%> (ø)
... and 11 more

... and 93 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[john-bodley]

@eschutho and @michael-s-molina I was wondering whether this PR would be a good candidate to have merged prior to the 3.1 cut given it refactors a non-trivial number of files.

[michael-s-molina]

LGTM

[eschutho]

@john-bodley This change looks really great!

@eschutho and @michael-s-molina I was wondering whether this PR would be a good candidate to have merged prior to the 3.1 cut given it refactors a non-trivial number of files.

This is already merged, so I'm late to respond, but in theory, I would say it would be good to merge refactors right after a minor/major release has gone out, so that the next release starts hardening on top of the refactor. But you're still going to be impacted for any patch releases. There's no way to make this perfect, of course.

[john-bodley]

@eschutho it's likely somewhat of a tough balance right? If you do this right after a major/minor release then it gives time for the master branch to harden, but it likely makes cherry-picking harder—as you pointed out. The value of merging these changes just prior to a branch cut, is the 3.0 branch will soon be a LTS branch and thus there's likely only going to be a few cherry-picks/reverts onto said branch, whereas most of the upcoming cherry-picks/reverts will be occurring on 3.1 which should be relatively pain free.