Fix SntpClient 2036 issue (2/2)

Fix issue with SntpClient after the end of NTP era 0 (2036).

This is the second of two commits. This commit makes the actual fixes
and makes tests pass.

Before this change SntpClient converted to Unix epoch times too eagerly.
NTP 64-bit timestamps are lossy: they only hold the number of seconds /
factions of seconds in the NTP era and the era is not transmitted. The
existing code assumed the era was always era 0, which ends in 2036.

As explained at https://www.eecis.udel.edu/~mills/y2k.html,
the lossiness of the type is not an issue providing that the maths is
implemented carefully: the NTP timestamps are only ever subtracted from
each other, are always assumed to be in the same or adjacent NTP eras,
and are used to calculate offsets that are applied to client Unix epoch
times.

This commit:

+ Switches to use a dedicated Timestamp64 type, avoiding the use
of the Unix epoch.
+ Switches to use a dedicated Duration64 type for holding the
32-bit signed difference between two Timestamp64 instances.
+ Simplifies the readTimeStamp() and writeTimeStamp() methods.
+ Adds missing validation covered by a TODO. The code was randomizing
the lower bits of the client transmit timestamp, but then not checking
the result as it should, presumably because it was difficult to know
what value was sent. Easily fixed with a dedicated type.
+ Stops randomizing the lower bits of various other timestamps
unnecessarily.
+ Fixes some naming to add clarity.

Bug: 199481251
Test: atest core/tests/coretests/src/android/net/sntp/Timestamp64Test.java
Test: atest core/tests/coretests/src/android/net/sntp/Duration64Test.java
Test: atest core/tests/coretests/src/android/net/SntpClientTest.java
Merged-In: I6d3584f318b0ef6ceab42bb88f20c73b0ad006cb
Change-Id: I6d3584f318b0ef6ceab42bb88f20c73b0ad006cb