Jobs scheduled in the future could get their deduplication key removed before they are started

This happens when scheduling jobs in the future for a very short period of time.

Instead, I think we should take the sum of the the time scheduled in the future and the ttl specified for the job

---

The following discussion from !73221 (merged) should be addressed:

• @reprazent started a discussion:

  There's a weird thing here. If we schedule a job 1s in the future, we end up setting a 1s TTL. So the lock could be released before the job that should have deleted it started.

  This isn't related to this issue though, but perhaps we should have this kind of thing:

  [time_diff, duplicate_job.duplicate_key_ttl].max