fix: creates audits as pending to prevent duplicate audits

[mrferris]

Puts content audit objects in the database as pending before starting an audit and then updates it with the result after, rather than only creating the audit object after.

Motivation is to fix an issue where the latest strategy starts auditing content keys that are already being audited.

[pipermerriam]

This uses the database as a "lock", which I don't think is the right approach here...

We should be able to implement a shared-in-memory-pure-rust version of this which seems highly preferred as it keeps our database schema from being more complex and specifically, it keeps us from having to implement what is effectively a state machine on this table to somehow ensure that records don't get left in awkward states like pending but never complete....

It should be easy-enough to implement something like a HashMap<Lock> that gets lazily created, held during the course of the audit, and then released and evicted from the HashMap....

Thoughts?

[pipermerriam]

I'm actually not even sure if the "lock" is required since we might just be able to have a HashSet which contains all of the content keys that are pending an audit...