Plugins should be aware of UiSettings values change

[mshustov]

In #82860 we had a case when a plugin wanted to perform a custom logic on value change.

User can adjust UiSettings in different ways:

• in UI
• calling UiSettings REST API
• calling SO REST API
• changing kibana.yml

We want to make sure that we cover all of the causes.

There are several different options:

• move UiSettings change to the plugin context. Therefore, plugins could perform any custom logic and call UiSettings API to write/read UiSettings
• still rely on AdavancedSettings UI, but provide a way for plugins to hook in platform API. For example, provide a stream of write operations to a plugin-owner, which can be used to implement any plugin-specific logic on top of it.

[elasticmachine]

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

[afharo]

This is blocking the removal of this deprecated API:

kibana/src/core/types/ui_settings.ts

Lines 81 to 89 in 8ee78d3

	/**
	* Metric to track once this property changes
	* @deprecated
	* Temporary measure until https://github.com/elastic/kibana/issues/83084 is in place
	*/
	metric?: {
	type: UiCounterMetricType;
	name: string;
	};

[TinaHeiligers]

Plugins should absolutely be aware of any changes to the settings that the plugin consumes. That being said, we could guarantee change awareness if a plugin were only allowed to consume a setting that it, itself, registers.

Unfortunately, this is not the case at the moment but I believe it will become more critical in situations where we cannot know before hand which, if any, plugins are not enabled in a particular offering.

[pgayvallet]

Note that if we do implement such a feature, depending on what we're planning to use it for, we may have to make it work for multi-instance Kibana (e.g instance1 update a setting -> instance2 need to somehow be aware of it)

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)