Fix silent deserialization failure with unique together constraint

[ozer550]

Summary

• Added IntegrityError to the caught exceptions in the deserialization pipeline so unique constraint violations are handled instead of silently ignored.
• Replaced the bulk upsert in the non-self-referential branch with per-record saves.
• Added regression tests in test_controller.py for the unique constraint scenario.

TODO

• Have tests been written for the new code?
• Has documentation been written/updated?
• New dependencies (if any) added to requirements file

Reviewer guidance

• Check if the regression tests make sense!
• Manually syncing two devices with voilating unique constraint for fields.

Issues addressed

closes #306

[ozer550]

This is so that the outer transaction stays healthy, and we can keep saving other records.

[bjester]

This is really mostly complete, just some cleanup and tidying code.

And the small deserialization_exception enhancement!

[bjester]

Perhaps we don't need this try/except anymore? So we can simplify this, leveraging the behavior of _save_deserialized_record

[ozer550]

I initially tried removing the try/except around _deserialize_store_model to reduce code, but I think keeping it is actually better. The reason is that there are two different things that can go wrong at two different moments. the json from the Store might fail having a deserialization failure. Second, our unique constraint violation case. clarity is worth the few extra lines?

[bjester]

The excluded_list doesn't seem necessary here, so maybe it's made optional for this function?

[ozer550]

We do execute excluded_list.append(store_model.id) to keep track of shared failed ids?

[bjester]

Yes but the purpose for that list is this very loop. So modifying the list is a bit redundant, and theoretically makes the in check slower every iteration without any benefit.

The store_model.id is unique and the same as app_model.id, so as this loops through the store+app models, if the ID gets added to the excluded_list, it will never come up again in the loop.

[bjester]

Strange, I did see the issue the CI. We already have transaction imported. Once the other stuff is tackled, it might be worth dropping the commit to see if it fails again.