Ignore repair_run_by_cluster_v2 rows with no corresponding repair

[SesquipedalianDefenestrator]

When bad things (like Reaper filling the drive with logs) happen, it's possible to end up with repair_run_by_cluster_v2 rows with no corresponding repair row, which breaks Reaper. So, just skip them.

[github-actions]

No linked issues found. Please add the corresponding issues in the pull request description.
Use GitHub automation to close the issue when a PR is merged

[SesquipedalianDefenestrator]

I'm not actually sure if anything will clean up the repair_run_by_cluster_v2 rows, but I'm not sure it's a problem. The mismatch between repair_run and repair_run_by_cluster_v2 is frequent enough to be a pain (basically, a percentage of the time when anything goes wrong with the cluster and Reaper logs until the drive fills), but not often enough to generate measurable load.

[SesquipedalianDefenestrator]

Looks like there's an issue for this already as well: #1463

[Miles-Garnsey]

I'm looking at this, having some issues with my local setup as far as testing goes so bear with me while I try to work around them.

[Miles-Garnsey]

In terms of testing, I've followed the procedure below:

Try to repro the issue from main by:

1. First commenting out the testSSLHotReload (which is a problem to run locally) then building the repo into a docker image, kind loading it into a kind cluster, spinning up a K8ssandraCluster with the new Reaper image.
2. Creating a new repair via the UI.
3. Confirming the repair exists in both repair_run_by_cluster_v2 and repair_run
4. Deleting from repair_run via delete from repair_run where id = d03c24a0-e59e-11ee-9a67-5dd395ae716d

When reloading the UI I then see:

Which I think is what we want based on the error repro'd here.

I then go and rebuild the image and re-deploy everything using the branch from this PR. Following the same procedure, I no longer see the NPE visible in Reaper's logs. Instead, the UI simply returns no results for repair runs in the DONE or RUNNING state.

I'm going to chat to @adejanovski about whether we need some more work to ensure that repair runs are purged from repair_run_by_cluster_v2, and whether this data inconsistency should be logged as a warning. But I'll approve this for now on the basis that it eliminates the NPE.