ct-test-srv: cap tracked submissions

[mcpherrinm]

When using long-running test environments, ct-test-srv grows until it OOMs, which is causing some noise in my efforts to right-size memory usage.

[Copilot]

Pull request overview

This PR attempts to bound memory growth in ct-test-srv by capping the number of distinct hostnames tracked for CT submission counts.

Changes:

• Adds a submissionsCap field and SubmissionsCap config option.
• Moves submission-count update logic into a helper intended to enforce the cap.
• Defaults the cap to 100 when unset.

Comments suppressed due to low confidence (2)

test/ct-test-srv/main.go:175

• The helper indexes the map with hostnames, but that identifier is only local to addChainOrPre and is not in scope here. This causes a compile error and also ignores the hostname argument.

	_, ok := is.submissions[hostnames]
	if ok || len(is.submissions) < is.submissionsCap {
		is.submissions[hostnames]++

test/ct-test-srv/main.go:169

• After removing the inline increment from addChainOrPre, this new helper is never called anywhere in the package. Even if the compile errors are fixed, successful CT submissions will no longer update is.submissions, so /submissions will always return 0 for new hosts.

func (is *integrationSrv) addSubmission(hostname String) {

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[mcpherrinm]

that's the idea. I don't think evicting or reset is useful for integration tests

[jsha]

Looks good in general. For Boulder CI let's configure the cap to something ludicrous like 1M. If we add test cases in the future that do lots more issuance, I don't want to wind up with a mysterious flake because sometimes we hit the cap and sometimes don't.