Prevent concurrent object access

[yhabteab]

This PR restructures the Object and Incident lookups and creations a bit to prevent some of the issues we were having as described in the referenced issues. Previously, the event processing logic goes like this:

1. With each ongoing request, we first sync the Object into the database in its own transaction. While this is happening, the entire objects cache is locked, so any other request that targeting a completely different object will be blocked until the transaction is committed.
2. After the object is successfully synced, we then proceed with the rest of the processing, which includes syncing the Incident and all the related records in a single and long transaction. And of course, while this is happening, the incident object is locked, so any other request that targeting the same incident will be blocked until the ongoing one completes.

This PR changes the logic to the following:

1. With each ongoing request, we first just retrieve the corresponding object from cache, and if it doesn't exist yet, we simply create a new one in memory without saving it to the database. This way, the objects cache is never locked across database transactions, and any request that targeting a completely different object can proceed promptly without being blocked.
2. After the object is retrieved or created in memory, we then use that object to lookup or create the corresponding incident in the incidents cache. Only when enter the incident.ProcessEvent function, and acquire the lock for that incident, we will then start a DB tx to sync the incident and all the related records just like before, but this time, the object syncing is included in this very same tx. When we receive another request that targeting the same object, it will be blocked in incident.ProcessEvent until the ongoing one completes, but other requests can freely proceed without such blocking.

There is one difference between the old and new logic that is worth mentioning. Previously, if we fail to successfully sync the object into the database, it wasn't added to the cache at all, as the cache is only updated after the tx is committed. That's not the case anymore, but since incidents are created/cached in the same way (even with the main branch), I don't have any better way to handle this without introducing more complexity. If in doubt, we can always add some cleanup logic or the like to remove dead objects and incidents from the cache in a later/separate PR if we find it necessary.

resolves #250
resolves #266

Blocked By

• Don't persist events,incident_events to DB #423
• Evaluate rules on our own #418 (this PR drops all extra tags related code, and would create a nasty merge conflicts. Plus when this PR is merged the failing GHAs will hopefully secceed 🤞🏼)