[Logs + Metrics UI] Clean up async plugin bootstrapping

[weltenwort]

Summary

In order to decrease the synchronously loaded script bundle size and thereby decrease the perceived loading time of Kibana, #62363 moves more of the plugin code behind asynchronous import. The complexity of the "infra" plugin bootstrap procedure prevented a more straightforward split with an async bundle for each of the sub-apps (i.e. Logs and Metrics) at the time.

To fully benefit from the lazy loading the unnecessarly shared compose_libs and start_app layers could be removed in favor of separate straightforward entry points for each of the apps.

Details

This would also be an opportunity to remove React context providers that have been superseded by the common new-platform provider and up-to-date router implementation.

Besides improved maintainability a reasonable benchmark for improvements would be the plugin-related bundle size that is eagerly loaded by Kibana compared to the lazily loaded bundle size. With the current new-platform build system each plugin is a self-contained set of JS files, one of which is always loaded with Kibana: plugins/${pluginName}/target/public/${pluginName}.plugin.js. The lazily loaded parts live in several ${N}.plugin.js files within that same directory:

drwxr-xr-x    - user  3 Apr 14:09 target/public
.rw-r--r-- 116k user  3 Apr 14:09 ├── 0.plugin.js      <-- lazily loaded
.rw-r--r-- 118k user  3 Apr 14:09 ├── 1.plugin.js
.rw-r--r--  43k user  3 Apr 14:09 ├── 2.plugin.js
.rw-r--r-- 1,9M user  3 Apr 14:09 ├── 4.plugin.js
.rw-r--r-- 654k user  3 Apr 14:09 ├── 5.plugin.js
.rw-r--r-- 157k user  3 Apr 14:09 ├── 6.plugin.js
.rw-r--r-- 132k user  3 Apr 14:09 ├── 7.plugin.js
.rw-r--r--  69k user  3 Apr 14:09 ├── 8.plugin.js
.rw-r--r-- 3,3k user  3 Apr 14:09 ├── 9.plugin.js
.rw-r--r-- 3,4M user  3 Apr 14:09 └── infra.plugin.js  <-- eagerly loaded

Ideally we would refactor the mount function in the Logs and Metrics app's core.application.register invocation such that

• infra.plugin.js is as small as possible
• navigating to the Metrics App lazily only loads the metrics-specific bundles
• navigating to the Logs App lazily only loads the logs-specific bundles

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[jasonrhodes]

Is there no way to do some kind of "Common Chunk" bundle splitting for things that are shared between plugins like this? Are we implementing some sort of arbitrary "no sharing between plugins" rule to maintain bundle size from now on? Curious how this affects us overall, I think I'm missing a little context though.

[weltenwort]

The context is that, with the removal of page reloads on navigation, just splitting the code into bundles is not sufficient if the bundles are still loaded synchronously (as was the case before). Since every NP-style-plugin's entry point is loaded eagerly now, we are responsible for keeping the entry point bundles as small as possible and using lazy imports of the biggest chunk of plugin code. I'm not sure how that interacts with code shared across plugin boundaries, but they might be duplicated with the goal of having self-contained plugin bundles for optimizer-free deployment.

[weltenwort]

By consulting with the Kibana platform team, I have learned that it is indeed correct that no code is shared between NP plugins except for a specially handled kbn-ui-shared-deps bundle. The migration guide has been extended to contain a basic explanation as well.

[weltenwort]

related: #63292