secure_time: true can never sync — guest chrony is built without NTS

从 meta-dstack/recipes-core/chrony/chrony%.bbappend 开始，将其 PACKAGECONFIG 与 upstream 的 chrony_4.8.bb 进行比较，然后检查 dstack-util/system_setup.rs 中 chronyc waitsync gate 附近的代码。构建一个启用 NTS 的镜像，并验证 chronyc 能够同步；同时跟踪 single-node 默认值，确保在不存在可信时间源时 secure_time 为 false。

Problem

Guest images ship /etc/chrony/chrony.conf with every time server set to NTS (server <host> iburst nts), but chronyd is compiled without NTS support. Chrony therefore has zero usable sources and never synchronizes.

Any app with secure_time: true — the manifest default (default_true) — then blocks in dstack-util system_setup.rs on chronyc waitsync, which bails → boot.error → reboot. On SEV-SNP this is a hard loop (cpus are not resettable, terminating → VMM restarts forever); on TDX it's a boot failure.

Confirmed from inside a running CVM:

chronyd 4.8 starting (... -NTS ...)
Missing NTS support
Can't synchronise: no selectable sources (10 unreachable sources)

chronyc authdata shows Cook=0 for all servers (NTS-KE never attempted), and the clock was already correct (stepped 0.000000s) — so it's not a network, clock, or platform issue.

It has gone unnoticed because every real deployment sets secure_time: false; the broken NTS sync is silent until the strict gate is enabled.

Fix

In meta-dstack, recipes-core/chrony/chrony%.bbappend adds DEPENDS += "gnutls" and an NTS config but never enables the NTS build flag. Upstream chrony_4.8.bb gates it behind PACKAGECONFIG[nts]. Add:

PACKAGECONFIG:append = " nts"

Then chronyd is built with NTS and secure_time: true can actually sync.

Separately, single-node/no-gateway deploys (no trusted time source) should default secure_time: false.