[nexus] avoid loading torn sitreps (#9627)

This commit fixes #9594 with regards to the sitrep load/delete
operations.[^1]

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 #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 #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)

[^1]: Which should be sufficient to close that issue, as #9603 and 
      #9604 already fixed the blueprint and inventory collection sides
      of the issue.

Author: hawkw