test: make the CrowdSec and handler tests repeatable in one process

[Wikid82]

Summary

Makes the internal/crowdsec and internal/api/handlers backend tests repeatable in one process (go test -count>1, -shuffle), and adds a cheap guard and a weekly check so it stays that way. This is unrelated test infrastructure; it does not change application code.

Closes #1548. Refs #1278 (the repo-wide shared-cache DSN problem; other packages stay tracked there).

Cause

Many tests built a shared-cache in-memory SQLite name from t.Name() (file:<name>?mode=memory&cache=shared). That database lives as long as one connection to the name is open, so the second iteration of -count=2 reopened the first iteration's data (UNIQUE constraint failed, and a panic at TestAuthHandler_GetAccessibleHosts_PermittedHosts). The issue understated it: 12 internal/crowdsec tests (including TestHeartbeatPoller_StatusTransition) and 28+ handler tests failed.

Changes

• testutil.MemoryDSN / OpenMemoryDB (taking testing.TB): a name never used before in the process, parameters appended, pool closed on cleanup. handlers.OpenTestDB now uses it.
• 24 handler test files and one CrowdSec test helper switched over by a scripted replacement; reviewed by diffstat and spot checks. No test was skipped, removed or weakened (the only other changed lines are imports).
• A guard test fails if any cache=shared literal appears in the two clean packages' test files (red/green demonstrated).
• A weekly (Thursday 05:00 UTC) and manually dispatchable workflow runs go test -race -count=2 -shuffle=<seed> over the two packages. Not a required check. About 18 minutes measured (one handlers iteration is about 7 minutes under -race); 60 minute test timeout, 75 minute job timeout.
• codecov.yml ignores only the new helper file.

Testing

• -race -count=3 and -shuffle=on -count=2 on both packages green (handlers -count=2 829 s, -count=3 1268 s; crowdsec -count=3 316 s).
• Backend coverage 91.3% statements / 90.3% lines; frontend 91.49%; patch coverage 90.0% (the uncovered lines are in the Codecov-ignored helper).
• Full golangci-lint config, govulncheck, Trivy (dependency files), local CodeQL and all pre-commit hooks clean. QA report: docs/reports/qa_report.md.

Notes

• GitHub only runs scheduled workflows from the default branch, so the weekly cron first fires after the next promotion to main; use workflow_dispatch to run it sooner.
• The guard covers only the two clean packages (about 190 cache=shared test lines remain elsewhere, tracked in test: shared-cache in-memory SQLite DSN collisions under -race + t.Parallel() (101+ sites) #1278).

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[github-actions]

✅ Supply Chain Verification Results

✅ PASSED

📦 SBOM Summary

• Components: 1870

🔍 Vulnerability Scan

Severity	Count
🔴 Critical	0
🟠 High	0
🟡 Medium	0
🟢 Low	0
Total	0

📎 Artifacts

• SBOM (CycloneDX JSON) and Grype results available in workflow artifacts

---

_{Generated by Supply Chain Verification workflow • View Details}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!