Fix a scheduling issue

Metrics suggest that there are some cases when the
NetworkTimeUpdateService POLL intent can fire much more often than
expected. There is no hard evidence yet for what is actually happening;
this commit contains a fix for one possible answer: the sharing of the
NtpTrustedTime singleton can lead to successful refreshes producing new
cached time results that aren't being handled properly. Recent changes
made the current scheduling logic more susceptable to problems here.

This commit makes changes intended to ensure that a callback cannot be
scheduled in the past. It also explicitly resets the mTryAgainCounter to
zero if there is a recent-enough successful time refresh to avoid using
the "short" polling interval incorrectly when the latest refresh was
successful.

A test has been added that fails with old logic and passes with new
logic.

Bug: 269425914
Test: Local manual testing
Test: atest services/tests/servicestests/src/com/android/server/timedetector/NetworkTimeUpdateServiceTest.java
Change-Id: I0ae4cd94badaf25a7b951d33fc6414ea3332863e