Refactor / all_as_schedule crontab query optimization

[alirafiei75]

This PR enhances the DatabaseScheduler's crontab exclusion logic to properly handle tasks with different timezone settings. The scheduler now correctly converts between timezones when determining which tasks to include in the schedule, making the scheduler more efficient by only loading tasks that might be due soon regardless of their timezone configuration.

[codecov]

Codecov Report

Attention: Patch coverage is 91.22807% with 5 lines in your changes missing coverage. Please review.

Project coverage is 88.07%. Comparing base (cf04a7b) to head (9eae52a).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
django_celery_beat/schedulers.py	89.36%	3 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #879      +/-   ##
==========================================
- Coverage   88.08%   88.07%   -0.02%     
==========================================
  Files          32       32              
  Lines         965     1006      +41     
  Branches      100      104       +4     
==========================================
+ Hits          850      886      +36     
- Misses         98      101       +3     
- Partials       17       19       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alirafiei75]

@auvipy
@Azurency

1. I have added a force logic to schedule property to force all_as_schedule to run if there was no change each 5 minutes
2. The server time was also wrong and I wrote a utility function that returns timezone.now() if USE_TZ is True and else returns an aware datetime with the timezone of the django project.

[Azurency]

@auvipy @Azurency

1. I have added a force logic to schedule property to force all_as_schedule to run if there was no change each 5 minutes
2. The server time was also wrong and I wrote a utility function that returns timezone.now() if USE_TZ is True and else returns an aware datetime with the timezone of the django project.

Nice, this seems great 👍. Working as expected with theses changes on my end.
Just a detail for consistency I would also use SCHEDULE_SYNC_MAX_INTERVAL in next_five_minutes = now() + datetime.timedelta(minutes=5) to prevent any changes to SCHEDULE_SYNC_MAX_INTERVAL to break the query (maybe it would be nice in the future to add a way to configure this max interval).

[auvipy]

Just a detail for consistency I would also use SCHEDULE_SYNC_MAX_INTERVAL in next_five_minutes = now() + datetime.timedelta(minutes=5) to prevent any changes to SCHEDULE_SYNC_MAX_INTERVAL to break the query (maybe it would be nice in the future to add a way to configure this max interval).

it would be nice to have part of this addressed, specially the check

[auvipy]

      # Current hour tasks in different timezones should not be excluded

  assert task_utc_current.id not in excluded_tasks, (

          "UTC current hour task should be included"
      )

E AssertionError: UTC current hour task should be included
E assert 13 not in {8, 9, 10, 11, 12, 13, ...}
E + where 13 = <PeriodicTask: utc-current-hour: * 8 * * * (m/h/dM/MY/d) UTC>.id

t/unit/test_schedulers.py:1125: AssertionError

[alirafiei75]

      # Current hour tasks in different timezones should not be excluded

  assert task_utc_current.id not in excluded_tasks, (

          "UTC current hour task should be included"
      )

E AssertionError: UTC current hour task should be included E assert 13 not in {8, 9, 10, 11, 12, 13, ...} E + where 13 = <PeriodicTask: utc-current-hour: * 8 * * * (m/h/dM/MY/d) UTC>.id

t/unit/test_schedulers.py:1125: AssertionError

The issue was with the mock aware now not being applied. I have resolved it.

[Azurency]

This looks fine 👍