AggConfig refactoring

[timroes]

Peter and I discussed recently some changes and refactoring we want to do around AggConfig, which I'd like to outline in this issue.

• Move the advanced JSON away from an AggParam and instead make it a property with getter/setter on AggConfig itself (setDslParamsOverwrite(params: Record<string, unknown>)). Then move the editor for it directly into the vis editor code, which will handle setting this property. AggConfig should take care of using this property after generating the DSL from all parameters for overwrite. Remove the JSON AggParamType after that.
• Do the same for the customLabel, move it to AggConfig with getter/setter and give it an editor.
  • Also remove the customLabels: boolean option on AggType, since we can set it on filters aggregations nowadays, and there should be no need for this anymore.
• Make AggType have one top-level toDsl method instead of every parameter having it's own write method. Currently every parameter writes itself out, or doesn't or very often just willy-nilly also handles other parameters. With one top-level method we will have a way cleaner approach to that.
  • AggParamType is still allowed to have a write method.
  • Call a toDsl(aggConfig: AggConfig, params: Record<string, unknown>) on the AggConfig when needing to generate the DSL. The params we'll pass in, will be already converted by the write method of the AggParamType if there was one (so e.g. the field parameter will already be the correct DSL, potentially a script depending on the field, and not just the plain field name).
  • The method itself returns us { aggName: string; params: Record<string, unkown>; parentAggs }, while parentAggs being the parent aggs as they exist already today.
  • That way we have one central place that generates the DSL, and parameters are not by default written into the DSL (will allow us to get rid of hundreds of write: _.noop. It also allows us to create different type of aggregations (e.g. date_histogram vs auto_date_histogram) depending on the specific AggConfig or parameters to it.
• Try to get rid of subAggs in the toDsl calls, by actually requiring the aggregation who wants sub aggregations to directly call toDsl on the AggConfigs of it sub aggregations and assign them to its aggs parameter in the DSL.

cc @ppisljar

Parent issue #60126

[elasticmachine]

Pinging @elastic/kibana-app

[elasticmachine]

Pinging @elastic/kibana-app-arch

[vadimkibana]

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.