Attach to subprocess changes in the new python debug adapter

[karthiknadig]

Pavel Minaev (@int19h) Please provide the details on changes to the attach config when attaching to a subprocess.

[int19h]

After discussing this, we decided to go with a more generic solution to avoid the unnecessary complexity on the IDE side. Instead, the debug adapter will create a fully formed debug configuration, and the IDE will use it as is. This makes things simpler for both the adapter and for the extension.

Instead of "ptvsd_subprocess" event that we had the adapter send to the IDE before, we'll now have a "ptvsd_attach" event. The body of the event is free-form, and directly represents the debug configuration for the subprocess DebugSession (i.e. it's exactly what would have been written in launch.json if somebody tried to attach to the subprocess manually). Thus, the extension doesn't need to interpret it - it can be passed as is to debug.startDebugging().

Further, unlike the current arrangement, where subprocess events are always sent in the session corresponding to the root process, the adapter will send this new event in the session corresponding to the parent process. This way, when the event is received by the extension, the new DebugSession can be created with the receiving DebugSession as the parent, with no need to do any name- or PID-based lookups to find the parent session.

On the adapter side, the body of the event is formed by taking the "attach" request for the parent session, and adding (or replacing, for sub-subprocesses) "subProcessId": <child-pid>.

[int19h]

Once we have this implemented and shipped, we should bring it up as a potential addition to the core DAP protocol - so that our custom "ptvsd_attach" event would become an "attach" DAP reverse request. The primary reason is to avoid the need to implement this IDE-side logic for other IDEs (e.g. if we want to do multiprocessing for VS).