Collect NTP zone debugging data

[karencfv]

Currently we collect debug data from the CI job for when chrony fails to sync time. We've recently had some issues with time syncing with a rack in the field and more debugging data would have been useful to get and understanding as to why time failed to sync during an update run until it was unblocked by a forced MUPdate.

[karencfv]

We should make sure to collect data about any connectivity issues as well

[karencfv]

Braindump on the implementation

• Today here is no specific threshold at which we consider time to have taken an excessive time to sync. Is it 5 minutes? 10? 20?
• Is collecting NTP zone debugging data from the very beginning excessive? Should we wait some time after the NTP zones have come up to start collecting data? Or should we just collect NTP zone debug data on an interval large enough that it can just run independent of how long the NTP time sync is taking?
• Should debug data stop being collected once time has synced?
• An NTP zone should report whether it's boundary or not. It was annoying to figure this out while debugging. The chrony-setup service has a property value boolean that determines whether a zone is boundary or not. Maybe I can use this