Safe debug agent. Part 2.

[mvicsokolova]

The previous changes to the debug agent provided a more detailed error message when agent initialization fails.
Though the question still remains: should we log an error and continue execution, or should we always throw an error?

For users who apply the agent manually and expect it to be attached, throwing an error that indicates the agent failed to load would be more helpful. But for the debugger users who didn't apply the agent manually (the debugger did it for them), a thrown exception is confusing —they have no idea where to add stdlib to the classpath or how to remove the javaagent, for them it just means that the debugger is broken.

To address both cases, I propose adding a special argument that the debugger can set to log an error and proceed with execution, while by default, an error will be thrown for manual agent users.

[mvicsokolova]

So, just for clarification of my point here. As I’ve mentioned in the first part of AgentPremain changes (#4524), we had a bunch of problems in the debugger related to the application of the debugger agent. I’ve briefly described them in this ticket: IDEA-378969. All of them were caused by the fact that all existing user run configurations do not have some unified api, which would allow to reliably check the classpath of this run configuration and make sure that kotlin-stdlib is available by the moment the debug agent is initialized. True, that's an issue on the debugger side 😞

Now, we reduced the number of cases, when the debugger tries to apply the coroutine debug agent to be sure, we do not apply it to run configurations, where it cannot be initialized. Now we only try to apply it to run configurations delegated to IDEA and Gradle projects. So, this agent initialization failure (NoClassDefFoundError: kotlin/Result) should not appear anymore, but in case there is some other bug left in the Gradle script, e.g. which contains the application logic for Gradle projects — the debug session will be broken again.

This whole problem will not exist anymore as soon as we adopt SPI, but for now having this special handle would help the debugger a lot, which would ensure, that the debug session will not fail, even if we applied the agent by mistake.

I do not suggest to advertise this argument in the error message for the users, who apply the agent manually — they expect the debug agent to be applied, it’s better for them to get an error right away and see, why the agent failed.

But we should not pass on this burden to the debugger users, who just want to debug their app, even without coroutine debug functionality (most of the affected users didn’t use coroutines in the debugged run config in the first place).