Do not use a job in the FileInfoReader

[laeubi]

The FileInfoReader currently creates a job just to join its execution, as the job is also marked as a system job to hide it from the users this does not seem very useful and only complicates the flow and increased the workload.

This now removes the job extension and also making the monitor field obsolete now.

[merks]

The existing design does make debugging and understanding the flows more challenging.

[github-actions]

Test Results

  375 files  ±0    375 suites  ±0   44m 7s ⏱️ +53s
1 904 tests ±0  1 901 ✅ ±0  3 💤 ±0  0 ❌ ±0 
6 712 runs  ±0  6 703 ✅ ±0  9 💤 ±0  0 ❌ ±0 

Results for commit b5ed068. ± Comparison against base commit 1d1d416.

[jukzi]

i wonder if the removal of join() will implicitly fix the deadlock eclipse-pde/eclipse.pde#1481

[laeubi]

i wonder if the removal of join() will implicitly fix the deadlock eclipse-pde/eclipse.pde#1481

There was never a deadlock. The JobManager is suspended at this time, that means join() return immediately so the code is running in circles as fast as possible because the (ECF Download) Job it is waiting here is never started.