ntpdate will unnecessarily trigger rate limit response from server

With verify_ntp_servers=true, the charm will issue a ntpdate command every 5 minutes (Juju's default) in the update-status hook on all of the units nearly at the same time. In a case where all units are behind SNAT, a ntp server will consider it's an unnecessary burst from a single IP address, then will return "rate limit response". In that case, the charm status will turn into an error even though the actual ntp daemon is synced with the upstream server.

Instead of generating a new set of packets in update-status hook, the charm can check the daemon's status with `chronyc sources`, `chronyc tracking` or something just to read the existing data.

$ ntpdate -qd ntp.ubuntu.com
27 Nov 06:45:31 ntpdate[244351]: ntpdate 4.2.8p12@1.3728-o (1)
Looking for host ntp.ubuntu.com and service ntp
91.189.89.198 reversed to chilipepper.canonical.com
host found : chilipepper.canonical.com
transmit(91.189.89.198)
transmit(91.189.89.199)
receive(91.189.89.199)
27 Nov 06:45:32 ntpdate[244351]: 91.189.89.199 rate limit response from server.
transmit(91.189.94.4)
receive(91.189.94.4)
27 Nov 06:45:32 ntpdate[244351]: 91.189.94.4 rate limit response from server.
transmit(91.189.91.157)
receive(91.189.91.157)
27 Nov 06:45:32 ntpdate[244351]: 91.189.91.157 rate limit response from server.
91.189.89.198: Server dropped: no data
91.189.89.199: Server dropped: no data
91.189.94.4: Server dropped: no data
91.189.91.157: Server dropped: no data

27 Nov 06:45:33 ntpdate[244351]: no server suitable for synchronization found