[relDB] Investigate safety of TreeSortMixin

[luisa-beerboom]

In the sort_tree method there's a TODO: "Check if instances exist in DB and is not deleted."

There is the possibility that the instances are already guaranteed to exist due to being found by the filter in the new system.
That really only leaves the question if any cached models that are marked for deletion may be found, or something along those lines.

We should take a look at the extended_database.py and the database_reader.py to see how the filter acts precisely. If the filter doesn't guarantee existance, that should be fixed, either in the mixin, or maybe better even, in the filter function. If everything's fine, the TODO can be deleted and this issue closed.

[luisa-beerboom]

Did some testing.
The mixin seems to have all required features for safety when used as sub-action in the same action as a create/delete action on a target model. The question is what happens if the sort actions are used at the same time as delete or create actions.
That currently fails and returns Unexpected error reading from database: could not serialize access due to concurrent update exceptions. I added some concurrency tests with 100 models each in #3309. Said tests currently expect the actions to go through, but all fail because of the error.
I skipped all these new tests because I don't know whether we want that exact error message there, or whether we want the actions to wait longer (or at all, I don't actually know if the root cause of this is a timeout-too-short thing or a we-aren't-waiting-for-locks-at-all thing).
This should be further looked into, possibly resolved, and the tests should be unskipped.

[luisa-beerboom]

The question is what happens if the sort actions are used at the same time as delete or create actions.
That currently fails and returns Unexpected error reading from database: could not serialize access due to concurrent update exceptions. I added some concurrency tests with 100 models each in #3309. Said tests currently expect the actions to go through, but all fail because of the error.

There is a TODO in the db_connection_handler.py stating that retry_on_db_failure is untested and needs to be adapted to psycopg3. Perhaps it has something to do with that.