fix: Use Celery task ETA for alert/report schedule

[john-bodley]

SUMMARY

After installing Superset with Celery to 5.3.0 (within the defined constraints) we started to notice an issue with Superset trying to parse a date/time string which was already of type datetime.

...
  File "superset/tasks/scheduler.py", line 81, in execute
    scheduled_dttm_ = parser.parse(scheduled_dttm)
  File "/usr/local/lib/python3.9/dist-packages/dateutil/parser/_parser.py", line 1368, in parse
    return DEFAULTPARSER.parse(timestr, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/dateutil/parser/_parser.py", line 640, in parse
    res, skipped_tokens = self._parse(timestr, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/dateutil/parser/_parser.py", line 719, in _parse
    l = _timelex.split(timestr)         # Splits the timestr into tokens
  File "/usr/local/lib/python3.9/dist-packages/dateutil/parser/_parser.py", line 201, in split
    return list(cls(s))
  File "/usr/local/lib/python3.9/dist-packages/dateutil/parser/_parser.py", line 69, in __init__
    raise TypeError('Parser must be a string or character stream, not '
TypeError: Parser must be a string or character stream, not datetime

I've spent a good amount of time perusing the Celery changelog and couldn't find anything which would have caused the regression, given that it seems we're using JSON for serialization/deserialization and there was no mention of the decoder trying to decode temporal arguments.

I did notice that there was some "magical" handling for the request ETA which, per here, tries to coerce the JSON encoded date/time into a datetime object. Digging a little future there seems to be some redundancy in how we define our tasks, i.e., providing both an ETA and a schedule which equate to the same thing.

This PR circumvents the problem by simply removing specifying the schedule in addition to the ETA which removes redundancy the need to decode the schedule. Note an alternative would be to tighten the constraint on the upper bound of feasible Celery versions, but this approach seemed more accomodating.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

CI.

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

[codecov]

Codecov Report

Merging #24537 (77ed88b) into master (7501134) will increase coverage by 0.14%.
The diff coverage is 100.00%.

❗ Current head 77ed88b differs from pull request most recent head 3e4b748. Consider uploading reports for the commit 3e4b748 to get more accurate results

@@            Coverage Diff             @@
##           master   #24537      +/-   ##
==========================================
+ Coverage   68.93%   69.07%   +0.14%     
==========================================
  Files        1903     1903              
  Lines       74027    74026       -1     
  Branches     8118     8118              
==========================================
+ Hits        51027    51135     +108     
+ Misses      20889    20780     -109     
  Partials     2111     2111              

Flag	Coverage Δ
hive	53.89% <33.33%> (?)
mysql	79.41% <100.00%> (-0.01%)	⬇️
postgres	79.49% <100.00%> (-0.01%)	⬇️
presto	53.78% <33.33%> (?)
python	83.48% <100.00%> (+0.30%)	⬆️
sqlite	78.00% <100.00%> (-0.01%)	⬇️
unit	54.65% <0.00%> (+<0.01%)	⬆️

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

Impacted Files	Coverage Δ
superset/tasks/scheduler.py	88.67% <100.00%> (-0.21%)	⬇️

... and 8 files with indirect coverage changes

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

[michael-s-molina]

LGTM