fix: use dynamic time_grains for schema

[eschutho]

SUMMARY

When testing out TIME_GRAIN_ADDONS from the config, although new time grains are working for line charts, they don't work for table charts:

This PR uses the built in time grains from the db_engine_spec and adds the time_grain_addons from the config to make the schema fields for the charts

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

after:

TEST PLAN

I didn't see any unit tests for schemas. It's typically a very static file. I can add a new test if it feels warranted. Otherwise, to manually test, add a new time grain for the selected db and test with different types of charts.

ADDITIONAL INFORMATION

• Has associated issue:
• 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

[eschutho]

@betodealmeida @villebro

[codecov]

Codecov Report

Merging #14009 (9f3c0dc) into master (f06d534) will decrease coverage by 0.35%.
The diff coverage is 100.00%.

❗ Current head 9f3c0dc differs from pull request most recent head 4e929c7. Consider uploading reports for the commit 4e929c7 to get more accurate results

@@            Coverage Diff             @@
##           master   #14009      +/-   ##
==========================================
- Coverage   79.21%   78.86%   -0.36%     
==========================================
  Files         936      940       +4     
  Lines       47408    47651     +243     
  Branches     5940     5998      +58     
==========================================
+ Hits        37554    37578      +24     
- Misses       9727     9946     +219     
  Partials      127      127              

Flag	Coverage Δ
cypress	56.04% <100.00%> (ø)
hive	80.28% <100.00%> (+<0.01%)	⬆️
mysql	?
postgres	?
presto	80.30% <100.00%> (+<0.01%)	⬆️
python	80.79% <100.00%> (-0.36%)	⬇️
sqlite	?

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

Impacted Files	Coverage Δ
...end/src/components/IndeterminateCheckbox/index.tsx	94.11% <ø> (ø)
...ntend/src/dashboard/components/CssEditor/index.jsx	70.83% <ø> (ø)
...nd/src/explore/components/DataTablesPane/index.tsx	57.74% <ø> (ø)
...ols/MetricControl/AdhocMetricEditPopover/index.jsx	77.09% <ø> (ø)
...et-frontend/src/components/TableView/TableView.tsx	96.42% <100.00%> (ø)
superset/charts/schemas.py	100.00% <100.00%> (ø)
superset/sql_validators/postgres.py	50.00% <0.00%> (-50.00%)	⬇️
...frontend/src/explore/components/DataTablesPane.tsx	24.69% <0.00%> (-38.28%)	⬇️
.../controls/MetricControl/AdhocMetricEditPopover.jsx	57.57% <0.00%> (-21.97%)	⬇️
superset/databases/commands/create.py	82.35% <0.00%> (-9.81%)	⬇️
... and 21 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f06d534...4e929c7. Read the comment docs.

[eschutho]

failed test looks like a connection error.. rerunning.

[eschutho]

front-end check error is an npm timeout, and I ran the tests/datasets/api_tests.py::TestDatasetApi::test_update_dataset_item_w_override_columns test several times locally and it passes every time.
It doesn't seem to be related, but lmk if someone thinks it is:

assert columns[0].column_name == dataset_data["columns"][0]["column_name"]
E       AssertionError: assert 'id' == 'new_col'

[eschutho]

🏷 rush!

[villebro]

LGTM!

[eschutho]

Thanks @suddjian and @villebro!
🏷 ready-to-merge

[yousoph]

🏷️ 2021.13