[Feature Request] Persist Boskos resource state to support decoupled `--up` / `--test` / `--down`

[Qqkyu]

We are migrating to kubetest2 and using a decoupled workflow (separate invocations for --up, --test, and --down) to run custom pre/post-test scripts.

We are hitting a blocker with Boskos lifecycles:

1. kubetest2 ... --up --boskos-resource-type=... --test=exec -- ./run-pre-test.sh acquires a project, starts the heartbeat and runs our run-pre-test.sh script.
2. The process finishes provisioning and exits. The heartbeat stops.
3. kubetest2 ... --test=clusterloader2 ... starts.
4. Mid-test, Boskos reaps the project because no heartbeat has been received since the first kubetest2 invocation finished.

We need a mechanism to resume sending a heartbeat for an existing Boskos resource in subsequent kubetest2 invocations. We currently see two potential implemention paths:

Option A: Add flags to manually pass the resource details. For example:

• --boskos-resource-name
• --boskos-resume-owner

This would also likely require setting environment variables in the Boskos acquire stage.

Option B: During Boskos acquire stage persist the data in --rundir. Subsequent commands running with the same --rundir could detect this file and start a heartbeat for that resource.

This feature would enable decoupled execution (which seems to be a roadmap goal) for any tests running on Boskos managed resources.

We've also considered the pre-test-cmd and post-test-cmd flags alternative. This would allow us to keep everything in one invocation, but it feels like a workaround that avoids fixing the issue and implementing a legacy pattern to patch a hole. However, if you think it's also a valid approach I'd be happy to discuss it.

I'd appreciate any comments, suggestions and hints about this and will happily implement it once I get a green light