[lldb-dap] Revisit runInTerminal process communication

[ashgti]

When using runInTerminal, lldb-dap uses a fifo to communicate between the lldb-dap process and the launched process.

This communication is flaky on some platforms, for example on arm CI hosts we disable this test and I've seen this be unstable in some cases as well.

Additionally, we've got some implementation quirks like the fact we leak std::future objects when a timeout occurs:

llvm-project/lldb/tools/lldb-dap/FifoFiles.cpp

Lines 62 to 69 in a63846b

	// Indeed this is a leak, but it's intentional. "future" obj destructor
	// will block on waiting for the worker thread to join. And the worker
	// thread might be stuck in blocking I/O. Intentionally leaking the obj
	// as a hack to avoid blocking main thread, and adding annotation to
	// supress static code inspection warnings
	// coverity[leaked_storage]
	return createStringError(inconvertibleErrorCode(),

I think it might be worth revisiting this approach, for example we could use a socket instead of a fifo.

[llvmbot]

@llvm/issue-subscribers-lldb-dap

Author: John Harrison (ashgti)

When using `runInTerminal`, lldb-dap uses a fifo to communicate between the lldb-dap process and the launched process.

This communication is flaky on some platforms, for example on arm CI hosts we disable this test and I've seen this be unstable in some cases as well.

Additionally, we've got some implementation quirks like the fact we leak std::future objects when a timeout occurs:

llvm-project/lldb/tools/lldb-dap/FifoFiles.cpp

Lines 62 to 69 in a63846b

	// Indeed this is a leak, but it's intentional. "future" obj destructor
	// will block on waiting for the worker thread to join. And the worker
	// thread might be stuck in blocking I/O. Intentionally leaking the obj
	// as a hack to avoid blocking main thread, and adding annotation to
	// supress static code inspection warnings
	// coverity[leaked_storage]
	return createStringError(inconvertibleErrorCode(),

I think it might be worth revisiting this approach, for example we could use a socket instead of a fifo.

[SuibianP]

FIFO: #121269
Windows FIFO semantics are rather different from POSIX. It was doable, but introduced more OS-specific hard-to-understand clutter.

Signal: #142374
Signal handling requires much care under MT, and may interact with debugging.

@ashgti - do you still want me to try and reimplement it with socket, or are you already halfway through?