Explore potential fix for CLion prematurely killing Bloom's process

There is a known issue with CLion managing Bloom's process; At the end of a debug session, CLion issues a SIGKILL to Bloom's process, forcing it to shutdown immediately, with no opportunity to safely release the connected hardware (debug tool and target). This issue sometimes results in subsequent startup failures, as the hardware is left in an unknown state.

This issue was reported to CLion's developers some time ago: https://youtrack.jetbrains.com/issue/CPP-28843

There may be a way to fix this within Bloom;

Key points (some of which are assumptions):

Before CLion closes the GDB connection and sends the SIGKILL, it issues the detach command via GDB - this results in the d (detach) packet being sent to Bloom's GDB server.
CLion appears to wait for Bloom to respond to the detach packet, before issuing the SIGKILL.
The issue only occurs when CLion manages Bloom's process. We can detect this by walking the process tree and looking for certain substrings (like clion.sh) within the name of each parent process. (<- not sure if there's a better way of doing this)

With the above points in mind, we could force the TargetController to suspend upon receiving the detach command packet from the GDB client. Suspending the TargetController will mean disconnecting from the debug tool and target. Once the TargetController has been suspended, we will send an OK response back to the GDB client, allowing it to disconnect. This means that, by the time CLion sends the SIGKILL to Bloom, we will have already released the hardware.

I'm not sure if this will work. The purpose of this ticket is to confirm it and explore its feasibility. Even if it does work, it's a nasty hack which I hope we'll be able to remove at some point later on, once the issue in CLion is addressed.

If it does work, I'd like to get it into v0.11.0, which is due for release soon.

bloombloombloom / Bloom

Explore potential fix for CLion prematurely killing Bloom's process #53