fix: revert "feat(sqla): apply time grain to all temporal groupbys"

[john-bodley]

Reverts #16318 per the comments left in the original PR.

Note I think the intent of the original change is good however it's somewhat nuanced and it was not apparent to the user from the UI that the grouping was being mutated. It does seem a preferred solution is either the addition of custom columns or UI components which allows users to opt in to which temporal columns should be transformed by the time grain. Furthermore said change was actually a breaking change but was not protected with a feature flag.

[codecov]

Codecov Report

Merging #17239 (d158742) into master (37909aa) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master   #17239   +/-   ##
=======================================
  Coverage   77.02%   77.02%           
=======================================
  Files        1037     1037           
  Lines       55629    55629           
  Branches     7594     7594           
=======================================
+ Hits        42850    42851    +1     
+ Misses      12529    12528    -1     
  Partials      250      250           

Flag	Coverage Δ
hive	81.52% <100.00%> (ø)
javascript	71.14% <ø> (+<0.01%)	⬆️
mysql	81.95% <100.00%> (ø)
postgres	81.96% <100.00%> (ø)
presto	81.82% <100.00%> (ø)
python	82.46% <100.00%> (ø)
sqlite	81.63% <100.00%> (ø)

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

Impacted Files	Coverage Δ
superset/connectors/sqla/models.py	87.39% <100.00%> (ø)
...eFilters/FiltersConfigModal/FiltersConfigModal.tsx	87.71% <0.00%> (+0.58%)	⬆️

---

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 37909aa...d158742. Read the comment docs.

[villebro]

Apologies for the regression introduced by the original PR. Having said that, it can be difficult to draw the line between what's a breaking change and what's a feature that was never really explicitly intended, and therefore not something that needs to be maintained. The reason for the change in the original PR was to enable something that is probably usually the expected behavior, as in the absence of per-column time grain configurations it is currently not possible to apply a time grain to multiple temporal columns without the change introduced by the original PR. But perhaps this change must wait for a better per-column time grain configuration UX (2.0?).

[john-bodley]

@villebro I agree with your comment. Additionally a poor UX, i.e., something unintended and sub-optimal, can become the de facto norm based on user behavior and or baked in work arounds. The issue then is future fixes—with good intend—are actually breaking changes given the saved formed data and thus a migration of some form (preferably non-breaking) is likely needed.