Preliminary breakpoints are not hit on second launch

[ivanbuhov]

Steps to reproduce:

1. Set some breakpoints
2. Launch on Android/iOS
3. Stop the debug session
4. Launch again without adding/removing breakpoints
   Expect the app to stop on the breakpoints added in step 1, but it ignores them. After adding a breakpoint in a random place in a given file, the debugger updates all breakpoints in the file and make them work again.

[petekanev]

I was not able to reproduce the described behavior when retracing the steps on a plain JavaScript app.

When I set breakpoints, and then restart the debug session multiple times the breakpoints register as expected.

Now, there are other quirks that disrupt the experience (especially pronounced on TS and NG projects), but those are logged separately.

I should note that the debug adapter listens for certain messages from the NativeScript CLI before sending an initialized event, which then allows VSC to send information about the breakpoints. At that point the application has already started, and any breakpoints set in the app initialization logic would have already executed. If we decide to support breaking on entry once again (NS pre 2.5), the --debug-brk functionality will have to be reimplemented on Android. Pausing for a couple of seconds will give the extension enough time to initialize before the application starts.

[BearOutThere]

Got the same problem. Steps to reproduce:

1. Build app with tns build android
2. Set break point
3. Run debugger from VSC.
4. Debugger stops at the break point as expected
5. Restart debugger from the debug tool bar or stop and then restart manually.
6. Application runs but debugger doesn't stop at the break point.

I would expect the break points to be active every time debugger is restarted. The application is based on the Drawer navigation template with minimal changes at this point.

Overall debugger behavior is unstable. Periodically page css is not getting loaded. When the debugger is running periodically it reloads the app by itself without any input or file changes whatsoever. I've been trying all sorts of permutations to identify the pattern of this behavior but to no avail.
Any help would be greatly appreciated.

Debugger connects to the app running in the emulator on port 40000 just fine. Attached is the diagnostic log.
vsc-debug-diag-log.txt