Persisted jobs versus incorrect boot-time RTC

Persisted jobs versus incorrect boot-time RTC

Devices routinely boot in a state where the RTC is wildly incorrect
in the past (2009, 1999, or even at Unix epoch zero).  When we have
persistent jobs to be scheduled at boot, this presents a problem: when
should those jobs run, given that our idea of "now" is incorrect?

The previous implementation fell back to rescheduling these jobs
"from scratch" in this situation, as though they were newly-introduced,
but this turns out to have some emergent pathologies when the jobs
were intended to become runnable after long initial delays: the
rescheduling behavior could wind up starving jobs out entirely,
never running them regardless of how much real uptime the device
had, given the "wrong" pattern of reboots.

We now preserve the original nominal schedule, but recognize when we
have booted in a pathological situation, and correct the schedule for
these jobs when the system clock becomes sensible.

Bug 63817592
Test: JobScheduler test suite plus manual bogus-boot-time repro

Change-Id: Ia36fc5298b68db74e4e07e973b68e68e66206b43