result_ttl deletes a finished job while a dependent that hasn't run yet still needs it

Hi, and thanks for RQ, we rely on it a lot.

We hit something with job dependencies that feels like a bug, and wanted to check with you before proposing anything.

When a job finishes, its result_ttl starts counting right away, even if it has dependents that haven't run yet. If one of those dependents only runs later, the dependency has already been evicted by the time the dependent runs, and the dependent fails looking it up.

Minimal repro (needs a local Redis): https://gist.github.com/jimzer/af1146df7220c9b043d98900c4928ca0

It enqueues A, then B depends_on A, runs only A, waits for A's short result_ttl to pass, then runs B:

after running A only:  A = JobStatus.FINISHED | B = JobStatus.QUEUED
A still in Redis?      False (B still depends on it and has not run)
after running B:       B = JobStatus.FAILED | rq.exceptions.NoSuchJobError: No such job: rq:job:...

Setting RESULT_TTL=3600 keeps A around and B finishes cleanly, so result_ttl is the only variable.

The way we see it, the result_ttl of a job that is still a dependency of unfinished jobs shouldn't count from when that job finishes, but from when its dependents are done. Basically, a finished result that something still depends on shouldn't be garbage collected yet. Everything else keeps the normal "clean up finished results after N seconds" behavior.

There are a couple of details to pin down (like what to keep if a dependent fails), happy to work through those. Does this match how you see it, or is there a reason it works this way today? If you're open to the direction, we'd gladly put together a PR (opt-in if you'd rather not change the current default).

Thanks!