Bug: when raw-streams are used, ensure system streams are set up

[cstamas]

When --raw-streams is used (especially when combined with options like --quiet and -DforceStdout) there is no guarantee that anything touches terminal. Hence, in case of embedded executor it is quite possible that cached/warm code arrives quickly at the place that would do system out before the thread with FastTerminal finishes system install.

In other words, when --raw-streams are used, we cannot guarantee that system streams are already properly set up. This PR changes that, and makes sure (by triggering a dummy call to terminal), at the cost of "jline3 install lag" for CLI invocation. OTOH, this lag in case of embedded executors does not exists (it exists only on first invocation).

My suspicion that this is the cause of IT instability issues, when Verifier used Toolbox output ends up on Surefire stdout and not on "grabbed" output, as simply streams are not yet set up properly. Also, this usually happens "around the second half" of ITs, when cached and warmed up embedded instance is already uber optimized.

[gnodet]

When --raw-streams is used (especially when combined with options like --quiet and -DforceStdout) there is no guarantee that anything touches terminal. Hence, in case of embedded executor it is quite possible that cached/warm code arrives quickly at the place that would do system out before the thread with FastTerminal finishes system install.

In other words, when --raw-streams are used, we cannot guarantee that system streams are already properly set up. This PR changes that, and makes sure (by triggering a dummy call to terminal), at the cost of "jline3 install lag" for CLI invocation. OTOH, this lag in case of embedded executors does not exists (it exists only on first invocation).

My suspicion that this is the cause of IT instability issues, when Verifier used Toolbox output ends up on Surefire stdout and not on "grabbed" output, as simply streams are not yet set up properly. Also, this usually happens "around the second half" of ITs, when cached and warmed up embedded instance is already uber optimized.

If I follow correctly, the problem happens when using raw-streams because the system streams are not modified in this case. In the default case, system streams are set and redirect to the logger, which then redirect to the terminal, thereby ensuring the FastTerminal is initialised.
So ensuring the terminal is initialised when using --raw-streams should fix the problem. Another possible way would be to setup system stream wrappers that would simply wait for the terminal to be initialised, before waiting for the stream to delegate, but the current PR looks much simpler.

[cstamas]

Yes, exactly as you wrote. But have to note, that IMO this affects ONLY "repeated embedded executor usage", hence ITs. There, embedded executor keeps "hot" embedded Maven, and as we saw, sporadically happens only (tl;dr toolbox plugin execution returns with empty string but without error, as stdout output landed on surefire out; causing all kind of havoc in ITs as given IT instead deleting own files starts deleting whole local repository). But, when it happens, it causes a range on weird issues and at the end IT failures.

One of these issues were recorded as apache/maven-resolver#1636 but now I am sure this is not a bug per-se, but in fact one of the "symptoms" of this bug (as two or more parallel executing IT make each other fails, by pulling the rug beneath them, as one just nuke local repository).