log: Avoid rounding headers sync progress to 100% #35198

<!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->

<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->

This applies the same progress formatting behavior as bitcoin-core/gui#935 to the node headers sync logs. During headers synchronization, the estimated progress was formatted with %.2f%%, which rounds to two decimal places. This could display 100.00% even when the estimate still had headers left to process. This patch formats the progress using fixed-point integer arithmetic, truncating to two decimal places instead of rounding. As a result, the log only displays 100.00% when the estimated number of blocks left is zero. The same truncation is applied to both headers sync and headers presync progress logs for consistency.

During a correct sync this is pointless, as the time were this error would happen is minimal, however in some special cases this can create confussion, please read https://github.com/bitcoin-core/gui/issues/65#issuecomment-4143720788 to get more context.

<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

There's a ~ there already indicating "approximately", synchronizing headers is fast anyway -- at 1M headers, 0.01% is 100 headers or 8000 bytes so should take a trivial amount of time to download/validate, and 100 headers is much smaller than how many headers are downloaded at once in general. This doesn't seem worthwhile to me.

It is true that during the ordinary sync this is not relevant, however during some special cases can be confusing, pls read https://github.com/bitcoin-core/gui/issues/65#issuecomment-4143517222 and https://github.com/bitcoin-core/gui/issues/65#issuecomment-4143720788 to get more context of the issue is trying to solve.

TL;DR: During the node syncing, if it crashes or is shut down, on restart it continues rebuilding the UTXO set. During this rebuild the node rejects new headers, so the last-known header timestamp becomes stale. After ~4 hours the percentage still rounds to 100%, creating a misleading “100% synced” display while headers haven’t updated for hours. Importantly, the rebuild itself doesn’t need to run for 4 hours, the issue also appears if the node is restarted after those ~4 hours have already passed, because the stored header timestamp is already stale at startup. In my node, the logs showed during 57 minutes 100% sync, when it was not, which is not a trivial amount of time.

The code you're looking for to change that is in qt/modaloverlay.cpp not the ones you've changed here? That code uses bestHeaderHeight + est_headers_left for the denominator, when it could use count from setKnownBestHeight which might be more precise.

The code you're looking for to change that is in qt/modaloverlay.cpp not the ones you've changed here?

I’ve already made the corresponding changes in qt/modaloverlay.cpp, please see the PR description. This PR targets the same underlying issue, but in the logging code rather than the GUI. From my perspective the problem is identical, the information is just shown in a different place. Can you explain why it is not the same?

when it could use count from setKnownBestHeight which might be more precise.

I don’t think that would be the right approach. Using setKnownBestHeight would still rely on a stale timestamp, so the resulting percentage would effectively reflect how many headers are sync to the local node donwloaded headers, rather than how close it is to the realchain tip. That would change the meaning of the metric and could mislead users about how much of the chain has actually been synced. I find a better solution calculating correctly the info instead of changing the meaning of the data avoiding addressing the underlying bug.