Fix faulty selection update when bringing project explorer to top

When link-with-editor is enabled, the IPartListener in LinkEditorAction
scheduled updateSelectionJob from both partActivated and
partBroughtToTop. This introduces two issues:
1. Selection updates are triggered just because the part is
(programmatically) brought to top, even if it is not activated, which is
unintended.
2. Both events fire for the same editor activation, so under normal
timing the second schedule() call merely resets the job timer and the
job runs once. However, on slow machines (CI on Linux/GTK) the two
events can fire more than LINK_HELPER_DELAY (120 ms) apart, causing the
job to complete from the first event and then be rescheduled and run
again from the second. This results in findSelection() being called
twice, which is not the intended behavior as indicated by breaking the
assertion assertEquals(1, findSelectionCount) in
testLinkHelperEditorActivation.

Fix: remove the job scheduling from partBroughtToTop. The partActivated
event is the correct signal for "an editor became active", which is
exactly what the link-with-editor feature needs to track.

Fixes #1338

Author: HeikoKlare

bundles/org.eclipse.ui.navigator/src/org/eclipse/ui/internal/navigator/actions/LinkEditorAction.java

@@ -149,9 +149,12 @@ public void partActivated(IWorkbenchPart part) {
 
 			@Override
 			public void partBroughtToTop(IWorkbenchPart part) {
-				if (part instanceof IEditorPart && !ignoreEditorActivation) {
-					updateSelectionJob.schedule(NavigatorPlugin.LINK_HELPER_DELAY);
-				}
+				// Do not schedule a selection update here:
+				// 1. when the part is just brought to top (programmatically) but not activated,
+				// no link update is expected.
+				// 2. scheduling from both partActivated and partBroughtToTop can cause
+				// the job to run twice when the two events fire more than
+				// LINK_HELPER_DELAY apart (intermittent on slow machines).
 			}
 
 			@Override