DAOS-18633 rebuild: throttle rebuild status logs to reduce overhead

[wangshilong]

Currently, each target dumps its rebuild progress to the log every 2 seconds unconditionally. In a large-scale scenario where a system has 100 pools rebuilding concurrently across 16 targets per rank, running for 10 hours can generate massive amounts of log data (several GBs per rank). This continuous, high-frequency logging (around 50 logs per second per xstream) causes severe I/O contention and negatively impacts overall I/O performance and ULT scheduling.

There is no necessary reason to print background progress logs this frequently. This patch throttles the rebuild status log dumping from 2 seconds to 5 minutes. The final status will still be printed immediately if a rebuild completes or aborts, ensuring that we retain sufficient visibility for debugging while avoiding log storms.

Steps for the author:

• Commit message follows the guidelines.
• Appropriate Features or Test-tag pragmas were used.
• Appropriate Functional Test Stages were run.
• At least two positive code reviews including at least one code owner from each category referenced in the PR.
• Testing is complete. If necessary, forced-landing label added and a reason added in a comment.

After all prior steps are complete:

• Gatekeeper requested (daos-gatekeeper added as a reviewer).

[github-actions]

Errors are Unable to load ticket data
https://daosio.atlassian.net/browse/DAOS-18633

[daosbuild3]

Test stage NLT completed with status UNSTABLE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos//view/change-requests/job/PR-17696/1/testReport/

[kccain]

any reason the leader loop doesn't use the same modulo approach as implemented in the tgt status loop?

[wangshilong]

any reason the leader loop doesn't use the same modulo approach as implemented in the tgt status loop?

I tried to avoid double when updating leader parts and over-optimize to avoid % operations, but forgot to update tgt status loop, but I guess this is not a big deal..