Add AggParamFilters to filter out params in vis editor

[jen-huang]

Similar to #19913 and #20539, this adds an additional AggParamFilters registry to filter out params for an aggregation type.

This is need to support rollups (#20004), notably to filter out missingBucket and otherBucket params.

Also includes a fix for if the default selected aggregation type is not part of the filtered agg type list, switch selection to the first available agg type: b9e6fe8

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[timroes]

I think we had some kind of miscommunication here :-) I thought that hiding parameters should be part of the EditorConfig in the end and not get it's own filter.

My reasoning behind that would be: aggregations and fields are kind of very special for all aggregations so I think they deserve their own filters (and for fields I already wondered if we shouldn't put that into EditorConfig but decided to have it separated). I think if we now start to create individual registries for everything we need to do with parameters (hiding, setting to fixed values, using a base), that will cause us to end up with a lot of super small registries what I would like to avoid. Also If we separate all those different "parameter configurations" we can't properly validate them against each other anymore (e.g. via proper typing). For example it doesn't make much sense to specify a base for a field and hide it, or later show a limitation warning (which would be part of the config) and hide the field.

If we put all of that in the config (like https://github.com/elastic/kibana/pull/20519/files#diff-ead2d626d94f97e12d549312159afedbR22) we can actually properly validate those and would only end up with one additional registry and not 3-5 more of them. This would also potentially make it easier to take over some of this code for the new editor (since with the current early stage we're having for the new editor, I am not sure if not all of those is throw away code after all).

Sorry that I didn't convey that idea properly in the beginning. What are your thoughts around that, since we can of course discuss all of that.

[jen-huang]

@timroes For some reason I was under the impression that EditorConfig was just for modifying other parameter configurations, I didn't realize it could also be used to toggle visibility 😄 I agree, it would be better to avoid micro-registries. Closing this!