Fix restarts always getting stuck "Initializing" when using CodeLLDB.
When using the restart command we re-use the configuration dict as-is,
so always re-use the same TCP port for the lldb socket. Originally it
was thought this was due to a race condition, having the port still
open, but it's not.
When doing a restart, or reset, we shut down the server after we get the
response to the disconnect message. CodeLLDB then also sends a
'terminated' message.
Previously we were forcefully closing the socket before killing the app,
after we get the 'disconnect' response. This meant that the OS buffer
for the socket to localhost:<the port> still contained the terminated
message at the point that we force-closed the socket and killed the
server.
The result was that the firt messages read from the "new" socket to
locahost:<port> were the last messagse written by the previous process,
trikcing vimspector into thinking that the server terminated the process
(before responding to the initialize request).
ANyway, the solution is to ensure that we read all messages from the
previous instance before considering it done. This is done by killing
the server if there is one *first* and then trying to read any messages
from the socket until it closes (reads EOF).
The tricky part is for when we didn't start the server (i.e. in a
multi-session setup). Here we simply _have_ to close the socket because
we can't know when we've received all of the messages, and we shouldn't
expect to receive any 'terminated' events after 'disconnect'.
We add a 'temporary' option to line breakpionts and try and clear any
temporary breakpionts on the line we end up stopping on. This might not
be art, but _probably_ works in almost all cases that matter.
it's a bit hacky the way we have to push the reason around, but we don't
know where we stopped until we actually get the stack trace response and
SetCurrentFrame
Move temporary breakpionts to match server response
Also delete any existing ones when adding a new one and add tests for
run-to-cursor.
Only continue after we successfully set the breakpoints. This makes it
work in go
These are useful for running tests (i.e. ensure there's a breakpiont at
the start of the test) and/or other programmatic usages.
They will also be needed for setting temporary breakpionts.
