If starting the internal clock fails we would still store a broken clock in the
cache despite it being unusable and never recovering.
Not storing it allows the application to simply create a new one at a later time
and have starting it retried.
Also signal to the application that such a clock is not synced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8334>
This reverts commit 779e715b6cee4f7793c43a0e78c6106ab66f1032.
Since the introduced corrupt clock state for when discovering a time
server restart, this resulted in previous similar check as done in
this patch became ignored/jumped over (in case of the corrupt state
has been noticed).
Reference: df41d11a7d7f844e593a10f6a6a0858333fbf7ec
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7664>
Clients that already gotten a signal for synced clock, may rely on
getting the same when marked as corrupted to take appropriate action. So
send clock signal indicating no sync at identified corrupted state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7664>
If the time server is restarted with a time in the past the net client
clock will not report the new time anymore as this would mean that the
clock moves back in time which it does not do.
Now the clock will be kept alive but marked as corrupted and will not
be re-used from the cache.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4802>
When detecting the remote time has been reset which may occur if remote
device providing the clock server has been power reset, then clock is
no longer synced. Setting clock state will trigger a signal to client
informing on sync lost making it possibility to take appropriate action.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/975>
