Use build parameters in DevModeInitializer when updating webpack config

[platosha]

In addition to maven plugin tasks, DevModeInitializer also triggers TaskUpdateWebpack to update webpack configuration before starting webpack dev server.

However, it is currently using hard-coded output paths instead of webpackOutputDirectory and resourceOutputDirectory parameters defined in FlowModeAbstractMojo.

Instead, those parameter values should be propagated somehow and used in DevModeInitializer.

[haijian-vaadin]

Related to https://github.com/vaadin/flow/issues/8953

[platosha]

In practice, this could make webpack produce output files in a wrong location.

A wrong output occurs when the following conditions are met:

• Maven configuration has overrides for webpackOutputDirectory or resourceOutputDirectory
• webpack-dev-server is configured to write files to disk (devServer.writeToDisk = true is set in webpack config, by default it is false).

This could also happen if DevModeInitializer is mistakingly run in production, which might happen if it is unable to find the flow-build-info.json token file. This should not happen to users, but occurred to me few times in a test project during development of the Flow itself.

With default configuration, there is no impact of this issue, because:

• In feature/offline branch the hard-coded directories are same as default configuration values (but they are different in current master)
• webpack-dev-server, even though has misconfigured output directory, does not write any files by default.

After we moved the webpack config generation from prepare-frontend to build-frontend in our feature/offline branch, the importance of this is more apparent. In development mode build-frontend is not invoked, so DevModeInitializer becomes the only source of webpack generated configuration data.

As a solution, consider generating webpack configuration in prepare-frontend task only, and removing TaskUpdateWebpack triggering from DevModeInitializer, so that the configuration is done in a consistent way in both development and production modes. For the offline features, this means that the @PWA annotation data, such as offlineResources list, should be propagated to webpack in some different way instead of being emitted in webpack.generated.js config, perhaps though a json file imported from the configuration.