AbstractTreeViewer do not auto-expand same nodes multiple times

[jukzi]

fixes slow (Quick-)Type hierarchy for redundant superinterfaces

eclipse-jdt/eclipse.jdt.ui#1830

[jukzi]

@fedejeanne for the example from eclipse-jdt/eclipse.jdt.ui#1922

[github-actions]

Test Results

 1 518 files   -   300   1 518 suites   - 300   1h 4m 11s ⏱️ - 31m 53s
 7 732 tests ±    0   7 503 ✅  -     1  228 💤 ±  0  1 ❌ +1 
22 703 runs   - 1 654  22 150 ✅  - 1 458  552 💤  - 197  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 8560cca. ± Comparison against base commit f878f80.

[fedejeanne]

I tested this in our big WS and it works like a charm: both the Type Hierarchy and the Quick Type Hierarchy of the problematic class (the "original Broke1") open in under 8s! 🚀 👏

[fedejeanne]

It just occurred to me: how does this PR affect other use cases where the user wants to expand the tree completely e.g. when he/she presses the button "Expand All"?
I'm away from the computer until Monday but I'd like to test this PR for more use cases before it gets merged. Can you please hold it, @jukzi ?

[jukzi]

While i guess, all our views would benefit of it there may be views downstream that may be confused. While it does not make sense to have such "loops" in a tree, there may be for example both a quicklink (favorite) and the subtree itself in a view (like in windows file explorer). I think it doesn't make sense to expand both but still adopters may not expect it. So i suggest you take this PR as a proof of concept, enhance it to offer the behavior as API and let usages like jdt opt-in. Could you please provide such PRs?

[jukzi]

to be replaced by #2692