[nexus] avoid loading torn sitreps

[hawkw]

This commit fixes #9594 with regards to the sitrep load/delete operations.¹

It makes the following changes:

1. Reorder the fm_sitrep_read query so that the sitrep metadata record is loaded last, and any loaded records are discarded should the metadata record no longer exist. This allows us to detect whether we have read a torn sitrep due to a concurrent delete (cda4f4d)
2. Change the fm_sitrep_delete_all query to use a transaction. The query is still a batched delete of multiple sitrep IDs, but this should be fine as the query does not SELECT the IDs to delete itself, and should therefore create a CRDB "write intent" only on the deleted rows. (1f0d6d9)
3. Some additional improvements to the fm_sitrep_delete_all query, adding a guard against deleting the current sitrep and changing the log level to INFO to match the similar blueprint/inventory delete queries. This isn't strictly necessary to fix It's possible to load a torn blueprint / sitrep / inventory #9594, but seemed worthwhile to do while I was here (0251720)
4. Add a knockoff version of @smklein's test for concurrent inventory deletes from PR Reorder inventory read to the end of loading #9604 that does the same thing except for sitreps (33547ed)
5. Change the fm_sitrep_read_current to correctly handle situations where it loads the current sitrep ID, and then, before it loads the sitrep records, a new sitrep is made current and the previous one is deleted (5f9b831)

Footnotes

1. Which should be sufficient to close that issue, as Reorder blueprint read to the end of loading #9603 and Reorder inventory read to the end of loading #9604 already fixed the blueprint and inventory collection sides of the issue. ↩

[hawkw]

argh i forgor to update the sitrep deletion test