Description of problem:
When chronyd configured with an NTS source not specified as offline and
resolvable without network was started before the network was up, it was
using an unnecessarily long NTS-KE retry interval, same as if the server
was refusing the connections.

When the network is down, the connect() call made from NKC_Start() on
the non-blocking TCP socket should fail with a different error than
EINPROGRESS and cause NKC_Start() to return with failure. Add a constant
2-second retry interval (matching default iburst) for this case.

Version-Release number of selected component (if applicable):
chrony-4.2-1.el8.x86_64

Actual results:

• After a reboot, chronyd started but NTS failed (the network is not ready yet):

~~~
Jun 15 10:20:39 myclient chronyd[1188]: chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
Jun 15 10:20:39 myclient chronyd[1188]: Could not connect to 1.2.3.4:4460 (1.2.3.4)

Jun 15 10:20:40 myclient systemd[1]: Started Network Manager.
Jun 15 10:20:40 myclient NetworkManager[1186]: <info> [1686817240.1199] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
Jun 15 10:20:40 myclient systemd[1]: Reached target Network.
~~~

Additional info:
This issue was fixed recently in the upstream code:

https://gitlab.com/chrony/chrony/-/commit/1daa40a2f759df30a7afe086c9f001d99fdd14a3
https://gitlab.com/chrony/chrony/-/commit/6270a3eb7cf8e35673cb19ea8e12bd6c8b15ede2

Normally this is not an issue for servers specified by hostname as the
NTS-KE connection will not be attempted until DNS responds (i.e.
network is already working), but if the server is specified with an IP
addresses, this delays in NTS-KE delay the first update of the clock
unnecessarily.