[Fleet] Allow combining agent configurations

[SHolzhauer]

Describe the feature:
This feature would allow to create an agent configuration and specify a "parent" configuration from which it will inherit properties.

Process:

1. Create a parent agent configuration, for example one for all your linux machines
   Most likely this would include the system integration and for future reference auditbeat parts
2. Create an agent configuration for a specific subset. E.g.: webservers
3. Activate the "parent configuration" option
4. Select the parent configuration
5. Add the integrations for this specific agent configuration
   This would be Apache, Tomcat or HaProxy for example

Describe a specific use case for the feature:
This will allow to enroll agents with a hierarchical nature and change integrations over multiple subsets of agents without having
to change every single configuration. Agents would enroll with the most specific configuration and inherit all of the parent configurations.

If there is no limit to parent configurations you can configure your own hierarchy within them, this would play nicely with orchestration like Puppet and Chef:

Global
  - linux
     - webservers
         - Apache
         - Tomcat
     - proxies
     - databases
  - windows

[elasticmachine]

Pinging @elastic/ingest-management (Feature:Fleet)

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[ruflin]

@SHolzhauer Our current thinking around solving this problem was to have reusable configs: #75867 With this we would prevent issues like dependencies of dependencies for example.

[mostlyjason]

Another way to achieve this effect is to have the parent policy specify all the inputs, and then use dynamic input conditions to enable/disable on selective basis elastic/beats#19225. The advantage of this is you don't run into issues where child policies conflict with parent policies.

[SHolzhauer]

@mostlyjason The idea here is to be able to build on top of other policies, you wouldn't overwrite them. Would always be an x + y = z casus.

@ruflin Reusable policies seems to do mostly the same, however the part I am missing is the dependency, or more accurately the forced update upon updating a "parent" configuration. (Or I'm misunderstanding #75867 ?)

[ruflin]

@SHolzhauer If one of the reusable policies is updated, it would also update each Agent config using this policy. The main difference between the two concepts is that in ours the Agent configs are composed of different policies, in your proposal there is a tree structure.

[SHolzhauer]

Closing in favor of #75867