Remove transaction

[btbest]

This removes a Transaction mechanism that was implemented in 2019 and then never used.

I am guessing that this was intended to allow us to remove a TransactionSlot that is used in a bunch of ops as a workaround, and judging by #2207, some "disconnect slot X first before we do this other thing so that we don't end up inconsistent in the meantime". Possibly also as an alternative solution to the current SetupDepthContext / call_when_setup_finished queuing mechanism that buffers setupOutputs calls correction: the SetupDepthContext is only used to prevent LayerViewerGui.updateAllLayers from running while the graph is being changed through Slot.connect, disconnect, setValue or setDirty. (That, plus a few notifyDirty with defer=True in countingGui and edgeTrainingGui.)

In the meantime, the additional piping through functions to check if a transaction is going on has been bloating stack traces unnecessarily since then.

We could keep some sort of archive branch with a revert of this commit in case we ever want to seriously implement it...

Current:

With this PR:

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 55.73%. Comparing base (60b582f) to head (4580a98).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2848      +/-   ##
==========================================
- Coverage   55.77%   55.73%   -0.05%     
==========================================
  Files         533      533              
  Lines       62253    62207      -46     
  Branches     8516     8511       -5     
==========================================
- Hits        34721    34668      -53     
- Misses      25777    25785       +8     
+ Partials     1755     1754       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[k-dominik]

Heya,

part of me is saddened that this never took off, but implementing transactions on that level made the stack traces indeed more complicated than they should be - something noone considered back then, and I think we just got used to it in the end. Your example is striking. I almost look forward to future exceptions during setup ;).

We need some sort of more natural transaction mechanism, than the once you can currently find in the code, so +1 on your suggestions to "archive" this transaction approach in a branch (maybe with an accompanying issue (could also be a comment in #2207), so it's a bit more findable).

[btbest]

The branch with the revert is here: https://github.com/ilastik/ilastik/tree/restore-transaction

Will crosspost on the other issue