Add a new NetworkTimeHelper impl

Add a new NetworkTimeHelper impl and changes to support it in the
time detector service code.

Background:

When the location code that became NtpNetworkTimeHelper was first
written, Android devices were not guaranteed to be requesting the time
regularly from network time sources: it was only done if the user had
enabled automatic time detection.

That changed a few releases ago, and so the location code should always
be able to ask the time detector for the latest network time signal.

This is part of a wider goal to remove several dependencies in the
Android platform on low-level NTP client code (NtpTrustedTime class).
The NTP protocol usage should be an implementation detail, not something
that is widely known to unrelated classes that want an accurate time.

With the new impl, the SDK SystemClock.currentNetworkTimeClock() call
will ask the time detector service for the latest network time too, and
not interact with the NTP client singleton directly as it does today. It
currently needs to use the NTP client because both the location code and
time detector use the NtpTrustedTime singleton independently and it is
therefore the closest thing on Android today to an authority of "what is
the latest network time the device has obtained?".

Once the time detector is the authority on "latest network time", it
will allow the platform to apply stringent checks to things like time
sync accuracy, which is currently not well checked and heavily dependent
on network round-trip time and network delay symmmetry.

This refactoring is also potentially important for form factors like
Wear, which disable NetworkTimeUpdateService and therefore won't trigger
NtpTrustedTime while attempting to sync. There's a good chance the
location time sync is also broken on Wear (if present) because of the
unusual networking constraints. The API
SystemClock.currentNetworkTimeClock(), which was added to the public SDK
in Android T, may be unreliable or broken on Wear. In future, Wear could
call suggestNetworkTime() on the time detector service from its own
equivalent of NetworkTimeUpdateService and restore
SystemClock.currentNetworkTimeClock() behavior, while also supporting
the location stack's needs (if that is also used on Wear).

Centralizing network sync under NetworkTimeUpdateService will mean that
fewer components on devices will be syncing time for their own ends,
potentially reducing load on time servers too.

This centralization also supports options for changing how "network
time" is obtained in future, e.g. allowing easier integration of newer
protocols like NTS or Roughtime, or partner plug-ins to support
proprietary protocols.

New implementation details:

The TimeZoneDetectorNetworkTimeHelper implementation retrieves the
latest network time suggestion from the TimeDetectorInternal API. It
attempts to pass time to the GNSS code as often as the original
implementation, even when a new time signal isn't available and its
potentially repeating itself, in case GNSS code has become reliant on
that. Generally, it's hard to tell what the contract should be,
particularly with the unusual behavior around "on demand" Vs "periodic"
and the historic bug there.

The new implementation should become the default when it is considered
safe to do so, i.e. after testing when we are confident that
NetworkTimeUpdateService is behaving as well as the old
NtpNetworkTimeHelper impl when detecting connectivity, etc. This can be
done with a single boolean compile-time flag.

Other changes:

The time detector is now a dependency of the location stack, so the
SystemServer service bootstrap ordering has been adjusted.

Bug: 222295093
Test: atest services/robotests/src/com/android/server/location/gnss/TimeDetectorNetworkTimeHelperTest.java
Test: atest services/tests/servicestests/src/com/android/server/timedetector/TimeDetectorStrategyImplTest.java
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector/TimeZoneDetectorStrategyImplTest.java
Change-Id: I2f9a14776e9fafe426213df7cb0307a3fe541fad