Fix concurrent publish operations causing missing package files

[agustinhenze]

When multiple repository operations execute concurrently on shared pool directories, race conditions could cause .deb files to be deleted despite appearing in repository metadata, resulting in apt 404 errors.

Three distinct but related race conditions were identified and fixed:

1. Package addition vs publish race: When packages are added to a local repository that is already published, the publish operation could read stale package references before the add transaction commits. Fixed by locking all published repositories that reference the local repo during package addition.

2. Pool file deletion race: When multiple published repositories share the same pool directory (same storage+prefix) and publish concurrently, cleanup operations could delete each other's newly created files. The cleanup in thread B would:

   • Query database for referenced files (not seeing thread A's uncommitted files)
   • Scan pool directory (seeing thread A's files)
   • Delete thread A's files as "orphaned"

   Fixed by implementing pool-sibling locking: acquire locks on ALL published
   repositories sharing the same storage and prefix before publish/cleanup.

3. Concurrent cleanup on same prefix: Multiple distributions publishing to the same prefix concurrently could have cleanup operations delete shared files. Fixed by:

   • Adding prefix-level locking to serialize cleanup operations
   • Removing ref subtraction that incorrectly marked shared files as orphaned
   • Forcing database reload before cleanup to see recent commits

The existing task system serializes operations based on resource locks, preventing these race conditions when proper lock sets are acquired.

Test coverage includes concurrent publish scenarios that reliably reproduced all three bugs before the fixes.

Checklist

• unit-test added
• functional test added/updated (if change is functional)
• author name in AUTHORS

[agustinhenze]

Sounds my new test is giving timeout (the new test takes longer than 2 minutes, of course depending on the load of the machine). @iofq or @neolynx would you mind taking a look. I can try to fix the timeout later, but an early review would be really appreciated.

I have found these multiple bugs after some stress testing I have done due to production bugs we had randomly.

[gaby]

Tests should be run with -race to detect race conditions