ci: add boot and init time enforcement to CI

[Unique-Usman]

Add automated boot and init time performance testing to prevent regressions.

• Enforces 100ms thresholds for both boot and init times
• Fails CI build if thresholds are exceeded
• Uses existing timing infrastructure from agentd
• Cleans up test sandbox automatically
• Add init_time to agent client connection logs for visibility

---

Fixes #473

[Unique-Usman]

Fix: #473

[Unique-Usman]

Also, when I tested the script locally, it uses about

Boot time: 36701211ns ~ 37 milliseconds
Init time: 35198971ns ~ 35 milliseconds
Boot performance test passed!

I set the BOOT_TIME and INIT max threshold to 100ms, may it should be higher or lower than this @appcypher ? Also, instead of parsing from log, do you think supporting some config file that return json for the timings is better approach ?

[toksdotdev]

this is heading in the right direction, but I don’t think log-scraping is the best long-term approach here.

the timing data already exists in the structured core.ready payload, so it’d be cleaner and less brittle to expose/read that directly in CI rather than parsing RUST_LOG output.

also, the workflow currently calls check-boot-and-performance.sh, but the script added is check-boot-and-init-performance.sh.

there's also a strong overlap between this PR and #552 (which i also have lots of reservations about).

[Unique-Usman]

erlap between

this is heading in the right direction, but I don’t think log-scraping is the best long-term approach here.

the timing data already exists in the structured core.ready payload, so it’d be cleaner and less brittle to expose/read that directly in CI rather than parsing RUST_LOG output.

Yeah, that is true.

also, the workflow currently calls check-boot-and-performance.sh, but the script added is check-boot-and-init-performance.sh.
mistake, I am sorry for that.

there's also a strong overlap between this PR and #552 (which i also have lots of reservations about).

Oops, I think this is a duplicate then, I am happy to close this unless @eric-14 does not want to continuing working on it, which I do not think so.

[toksdotdev]

yeah, i'd rather have the tests in rust, and #552 is much closer aligned to that than yours. so i'll proceed to close this. appreciate the PR though. 🙌🏽