Replace services modules by passing down references explicitly

[flash1293]

In a lot of places we are currently using the "services module" pattern to pass down references to global services within the plugin. In most cases the createGetterSetter utility from the utils package is used to store the references in a plugin-global module which is imported in the places the services are required.

Examples:
https://github.com/elastic/kibana/blob/master/src/legacy/core_plugins/kibana/public/discover/kibana_services.ts#L51

https://github.com/elastic/kibana/blob/master/src/legacy/core_plugins/kibana/public/visualize/kibana_services.ts#L67

https://github.com/elastic/kibana/blob/master/src/legacy/core_plugins/vis_type_table/public/services.ts#L23

This has several downsides:

• When parts of a plugin are exported statically, they are not allowed to use this "services module", because it won't be filled with a reference as it will end up in another bundle. There is no way to statically check for these cases and it's often hard to see whether a piece of code is relying on state this way.
• Unit tests are more difficult because the services file has to be mocked out for every test
• It is possible to introduce lifecycle race conditions (e.g. calling a piece of code relying in the setup phase which relies on a services module populated in the start phase). These cases can't be checked for statically which means they are hard to find just by looking at the code

All these problems go away when all dependencies are passed down explicitly from the plugin class of a plugin:

• When something is statically exported, its call signature will include the required services and every consumer will know they have to provide them. If they don't, the typescript compiler will catch the problem
• For unit tests service mocks can simply be passed into the components to test, mocking is not necessary
• Lifecycle race conditions will be caught by the Typescript compiler

Lens and Dashboard are doing it this way:

https://github.com/elastic/kibana/blob/master/src/plugins/dashboard/public/plugin.tsx#L247

https://github.com/elastic/kibana/blob/master/x-pack/plugins/lens/public/plugin.tsx#L90

This helper is useful in closing the gap directly in the plugin class in cases where start services have to be accessed in a sync fashion: #63720

To avoid these problems, existing code should be refactored to avoid services modules. This can happen incrementally over time.

• input_control_vis
• vis_type_markdown
• vis_type_metric
• vis_type_table
• vis_type_tagcloud
• vis_type_timelion
• vis_type_timeseries
• vis_type_vega
• vis_type_vislib
• discover
• dashboard
• visualize
• home

[elasticmachine]

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

[stratoula]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.