Migration for timezone aware timestamps

[jedrazb]

Relates to #2067

Followup to #2067. I realised that migrating from naive to offset aware timestamps for job scheduling might break existing connectors that had scheduling enabled and were using naive datatime (no tz info) representation.

I tried this scenario, as expected after migrating to new offset aware logic the scheduling was broken ... I got a following error from a scheduler

  File "/Users/jedr/connectors-python/connectors/services/job_scheduling.py", line 207, in _should_schedule
    and last_sync_scheduled_at > last_wake_up_time
TypeError: can't compare offset-naive and offset-aware datetimes

The fix is to try to cast naive datetimes, to offset aware datetimes when reading last_access_control_sync_scheduled_at, last_incremental_sync_scheduled_at and last_sync_scheduled_at from ES index. This essentially takes care of the migration.

I modified _property_as_datetime function to try to set datetime to UTC timezone, with the with_utc_tz function.

The _property_as_datetime is used by following properties in protocol logic:

• last_incremental_sync_scheduled_at this migration
• last_access_control_sync_scheduled_at this migration
• last_sync_scheduled_at this migration
• last_seen - already indexed as offset aware timezone (no effect on logic)

Verification

• Tested migration manually (enable all sync scheduling, execute some syncs, upgrade connectors, scheduling still works fine)
• Unit tests

Checklists

Pre-Review Checklist

• this PR has a meaningful title
• this PR links to all relevant github issues that it fixes or partially addresses
• if there is no GH issue, please create it. Each PR should have a link to an issue
• this PR has a thorough description
• Covered the changes with automated tests
• Tested the changes locally
• Added a label for each target release version (example: v7.13.2, v7.14.0, v8.0.0)

[artem-shelkovnikov]

I think it's also worth to add a comment here mentioning the problem found and saying that it's done here for backwards-compatibility

[jedrazb]

Okok, added the comment!

[github-actions]

💔 Failed to create backport PR(s)

The backport operation could not be completed due to the following error:
There are no branches to backport to. Aborting.

The backport PRs will be merged automatically after passing CI.

To backport manually run:
backport --pr 2587 --autoMerge --autoMergeMethod squash

[artem-shelkovnikov]

@jedrazb any objections to backporting it back up to 8.13?