Stricter Setup / Start API separation

[mshustov]

From the very beginning Kibana platform uses a notion of lifecycles to separate runtime process into different stages:

• setup - the preparatory stage. It should be used to declare cross-plugin dependencies and dependencies on the platform functionality. Kibana remains at this stage for a limited amount of time. In the future, this amount of time may be reduced to one tick.
• start - the runtime stage. Meant to be used to perform the Kibana functionality. It's a long-running stage. Kibana is in this state most of the time while it's running.
• stop - the teardown stage. It might be used to clean up resources and stop ongoing operations.

However, all the stages exist merely as a convention. This has led to the fact that plugins (and the platform itself) mix functionality up and provide runtime API from setup phase. As a result, when the platform decided to refactor public contracts we have realized it cannot be done due to the number of existing external dependencies. Not the full list of the blocked tasks:

• https://github.com/elastic/kibana/issues/55397

To prevent problems in the future, we are going to reinforce the separation of the lifecycle stages. Otherwise, we have to add defensive checks in the code that API can be called, which is an error-prone approach. By default API exposed from start lifecycle stage unless it's crucial to move it to the setup stage

Suggestions:

• to move platform API meant to be used in runtime to the start phase.
• identify plugins that can be affected by this change and create issues for code owners to refactor the public API.
• add a tracking mechanism to monitor all the cases when API is called from a not-relevant stage.
• fix all the problem places.
• enforce a hard separation for API. Invoking API from another stage will throw an exception.

Child tasks:

• https://github.com/elastic/kibana/issues/55396

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[mshustov]

a preliminary list of changes on the server side to understand the magnitude of refactoring:

• all the http API except create router https://github.com/elastic/kibana/blob/e67cc8514aa7aeb2e5a54bc1af2a61da19470fe3/src/core/server/http/http_service.ts#L103
• context service API https://github.com/elastic/kibana/blob/0f8533730c4d777669e590f9bc8796f394e55d68/src/core/server/context/context_service.ts#L34
• uuid service service API https://github.com/elastic/kibana/blob/9bdd23a460b31443fa8cf4c656600c659aa268e5/src/core/server/uuid/uuid_service.ts#L58
• status service API https://github.com/elastic/kibana/blob/f84773faed53cf0c3683406d5eaccb5f51975cda/src/core/server/status/status_service.ts#L59
• getImportExportObjectLimit from saved object service API https://github.com/elastic/kibana/blob/97d1685c3dea682f80fd1a907bbc1d6f3702ea85/src/core/server/saved_objects/saved_objects_service.ts#L163
• rendering service API https://github.com/elastic/kibana/blob/af09fedaf2dca691c4d81b5a0f83b0f9d8179c53/src/core/server/rendering/rendering_service.tsx#L49
• metrics service API https://github.com/elastic/kibana/blob/1f8da9dd7726596fd80658d48cbdf2b89e7c7855/src/core/server/metrics/metrics_service.ts#L52
• docLinks service API
• fatalErrors service API https://github.com/elastic/kibana/blob/4ff4b54e301c6439e531137c1040c0b755dc2521/src/core/public/fatal_errors/fatal_errors_service.tsx#L115
• http service fetch, delete, get, head, options, patch, post, put, addLoadingCountSource, getLoadingCount$
• Notifications toasts API
• UiSettings https://github.com/elastic/kibana/blob/4ff4b54e301c6439e531137c1040c0b755dc2521/src/core/public/notifications/notifications_service.ts#L60

[joshdover]

context service API

I believe this one should still be in setup since it is used to expose a context provider registry to other plugins.

[pgayvallet]

all the http API except create router

We even want to move to start the lifecycle hook registrations such as registerOnPreAuth ?

[mshustov]

We are going to start with logging a warning whenever lifecycle API is called outside of the current lifecycle timeframe https://github.com/elastic/kibana/issues/124039