The board discovery might miss detecting detached board when the package index is being updated

[kittaakos]

Describe the problem

Originally from #1181:

There is a bug with #1167 that can be reproduced on my Windows machine with the following steps:

• IDE2 is up and running, a board is connected and recognized by IDE2; it's the selected board,
• Stop IDE2,
• Start IDE2 (You can see the board is connected from the dropdown),
• Disconnect the board when the Downloading .... notification message (this is when IDE2 initializes the core client),
• Core client reinitialization is done, the board is not connected, but IDE2 still shows it as a connected board.

This PR fixes this issue, but IDE2 must stop the board discovery before re-initializing the core client and restarting after it. WheIDE2 stops the board discoveryE2 before the re-init; zero available board and ports must be broadcasted to the frontends. So users will see a disconnect/reconnect board before/after the index update and the core client re-init.

If the IDE2 misses the board detachment event, the boards selection dropdown will show the board as a connected one although it was detached. Attaching + detaching the board should solve this problem.

To reproduce

Note that the bug cannot be reproduced consistently.

Please reference the description of this issue.

Expected behavior

The detached board is tracked by the IDE2 during the indexes update/core client re-initialization.

Arduino IDE version

a003831

Operating system

macOS

Operating system version

12.3.1

Additional context

I could only reproduce the defect from my slow Windows env, running the IDE2 from the source.

• When running from the sources, the IDE2 is significantly slower: #1031 Restored the Settings UI. Deferred model loading. #1046 (comment)
• I had tons of platforms installed on my Windows env. Maybe this is a timing issue, and the InitRequest takes significantly longer: #637, #906: Update package index on 3rd party URLs change. #1132 (review)
• I had one single 3rd party URL set: http://digistump.com/package_digistump_index.json

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the latest nightly build
• My report contains all necessary details