Fork process with spring-boot:run by default

[snicoll]

The maven plugin currently has some logic to fork the maven process if necessary (e.g. if the path to an agent is set or if devtools is on the classpath).

This can have surprising side effects. Even though, this is not recommended, specifying "raw" system properties on the command line are transmitted to the Spring Boot application when the process is not forked. Currently, adding devtools would break that as this isn't the case when the process is forked.

Gradle always fork the process so those are two good reasons to align and always fork the process by default as well.

We'll flip the default of the fork property so that users have an escape hatch while migrating.

[wilkinsona]

The new optimizedLaunch setting that's proposed in #16222 will mean that a new JVM is forked by default. To avoid forking a new JVM, a user will have to set optimizedLaunch to false, thereby removing the JVM arguments that are used for the optimization.

[wilkinsona]

On second thoughts, having reviewed #16941, I think we should tackle this the other way around. Once we've switched to forking the JVM by default, we can then add the launch optimization arguments when forking the JVM. If the user sets optimizedLaunch to false, the arguments will not be added. If the user disables forking, the JVM will not be forked and no optimisation will occur, irrespective of the configuration of optimizedLaunch. We could log a warning if optimizedLaunch has been explicitly set to true and forking has been disabled.

[snicoll]

We could log a warning if optimizedLaunch has been explicitly set to true and forking has been disabled.

@wilkinsona that's what we already do for other features (such as devtools) and that plan aligns nicely with what we have now (I think).