Optimize Kibana app bundle sizes

[flash1293]

Currently the plugins of the Kibana app team import a lot of redundant code. To speed up loading times of Kibana, we should try to minimize the size of the initial code bundle which is shipped and executed every time Kibana is loaded. There are two general ways to do so:

• Get rid of code completely (in case it's not even needed and bundled in because tree shaking doesn't work yet)
• Loading things lazily only when required

This issue lists out places for possible quick wins in bundle size improvement:

Plugin boundary optimization

• The home plugin exports FeatureCatalogueCategory which causes it to be bundled in a lot of plugins. Can be avoided by converting to a string union
• The data plugin export AggGroupNames which is used in some visualization plugins. Can be avoided by converting to a string union
• A lot of visualizations are pulling in all of data for some helpers out of esFilters and esQuery helper collections. It would help a lot to move these into a separate plugin (since they are stateless) and make it part of the shared dependencies (not sure how feasible)
• The vis_default_editor plugin is just static code used in a lot of places. It can be moved into a shared dependency (like react)
• d3 is used in a bunch of visualization plugins and it's difficult to remove it completely - probably makes sense to move into a shared dependency as well
• Lodash is used all over the place - it definitely makes sense to move it into a shared dependency

Plugin optimization opportunities

vis_type_vega

• In src/plugins/vis_type_vega/public/vega_visualization.js import VegaView and VegaMapView lazily (should make all of the heavy dependencies lazy)

vis_type_timelion

• In src/plugins/vis_type_timelion/public/timelion_vis_type.tsx pull in TImelionVisComponent as lazy react component.

vis_type_table

• In src/plugins/vis_type_table/public/vis_controller.ts, import getAngularModule and initTableVisLegacyModule lazily

vis_type_metric

• In src/plugins/vis_type_metric/public/metric_vis_type.ts, import MetricVisComponent as lazy react component

vis_type_markdown

• In src/plugins/vis_type_markdown/public/markdown_vis_controller.tsx, import MarkdownVisComponent as lazy react component

charts

• In src/plugins/charts/public/services/colors/colors.ts import MappedColors lazily and only instantiate when createColorLookupFunction is actually called (should get rid of d3 in a few places - only relevant when we can't get it in the shared dependency bundle)

visualize

• Looks like data is only bundled in because of the usage of esFilters in src/plugins/visualize/public/plugin.ts
• DefaultEditorController can be imported lazily in src/plugins/visualize/public/plugin.ts, and made a type import (maybe by factoring out the methods into a separate interface) in the src/plugins/visualize/public/kibana_services.ts usage (not sure whether necessary)

dashboard

• Looks like data is only bundled in because of

  kibana/src/plugins/dashboard/public/plugin.tsx

  Line 43 in 2f794e6

  esFilters,

  (used in a single place to check whether filters are pinned) (~40% savings)
• Usage of initAngularBootstrap in

  kibana/src/plugins/dashboard/public/plugin.tsx

  Line 60 in 2f794e6

  initAngularBootstrap,

  (used to prepare angular stuff, but this can be moved into the lazily loaded application) (3% savings)

graph

• Some lodash helpers used in x-pack/plugins/graph/public/helpers/saved_workspace_utils.ts - looks easily avoidable
• Usage of initAngularBootstrap in

  kibana/x-pack/plugins/graph/public/plugin.ts

  Line 13 in 7d12b76

  import { initAngularBootstrap } from '../../../../src/plugins/kibana_legacy/public';

  - can be moved into the lazily loaded part

@restrry

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[flash1293]

I consider the low hanging fruits to be picked, the rest is tracked in #58280