TestCronVulnerabilitiesCreatesDatabasePath is flakey

[lucasmrod]

TestCronVulnerabilities* tests are flaky on CI PR checks (which slows down development).

See https://github.com/fleetdm/fleet/actions/runs/11522937945/job/32079864819.

This started happening after we enabled panics on cron jobs on CI (#21292).

{"cron":"vulnerabilities","err":"lstat /tmp/TestCronVulnerabilitiesCreatesDatabasesPath1788788500/001/something: no such file or directory","level":"error","msg":"analyzing mac office products for vulnerabilities"}
{"cron":"vulnerabilities","instanceID":"test_instance","level":"debug","msg":"close schedule","schedule":"vulnerabilities"}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x136576a]

goroutine 65 [running]:
github.com/fleetdm/fleet/v4/server/mock.(*DataStore).ListSoftwareForVulnDetection(0xc00b83ef08, {0x1cd9a40, 0xc00b80ab40}, {0x0, {0x18d62e4, 0xd}, {0x18ce0c8, 0x8}})
	/home/runner/work/fleet/fleet/server/mock/datastore_mock.go:4099 +0x10a
github.com/fleetdm/fleet/v4/server/

[iansltx]

So, this test looks like it should panic a large percentage of the time, as it's intentionally cutting off execution early, as the condition it's testing for is quite early in the cron run, but the vulnerabilities cron intentionally doesn't easily bail out for errors after the directory create call is made. So to quickly perform the test, we basically cancel the context after ~30 seconds, and that context cancellation can leave things in a messy enough state to cause panics. Those panics don't actually matter, as we're testing behavioers that happen well before where the panics happen, but they still have to be recovered, and recovery in a cron inside a test now fails that test.

My current plan is to run cronVulnerabilities() directly instead of inside a schedule (but still in a goroutine so we can watch for the dir existing in the main thread), and defer recovery inside the test rather than using the recovery apparatus built into the cron system (which would write log lines that would fail the job). As part of this, we can be much more aggressive about how quickly we cancel the text context as the action we're looking for is much earlier in the flow and we aren't waiting for a tick to happen.

This does mean that this test will no longer test cron apparatus, but we have e.g. TestCronVulnerabilitiesSkipMkdirIfDisabled to ensure our cron system works properly.

[lucasmrod]

+1 on the approach.