Aggregation Framework Refactoring meta

[polyfractal]

This is a running list of things in the agg framework we might like to refactor.

Agg framework

Agg boilerplate simplification.

Aggregations require a lot of boilerplate. Most aggregations will require a Builder, Aggregator, AggregatorFactory, result interface, parsed result interface and Internal result object. Simplifying this would make it easier to develop new aggs and collapse the agg package considerably

#43664

ValuesSource/ValuesSourceConfig/ValueType/ValueSourceType

We have a number of classes and enums that represent what kind of data a field is. They all exist for variously good reasons, but it's difficult to grok their purpose as a new developer and how they all interact. If we could simplify or unify them somehow it would be helpful.

Or at the very least come up with clearer names so their purpose is more obvious. And javadocs explaining their purpose

#42949

HashCode/doHashCode/doInnerHashCode

DONE: The agg framework has mixed style when it comes to asking child objects for their hashcode. Some override hashcode directly, some require doHashCode or even doInnerHashCode(). Doesn't really matter which style is used but it should be consistent

#43214

equals/doEquals/doInnerEquals

DONE: Same as hashcodes, but with equals

#43214

Replace DocValuesIndexFieldData builder with static methods?

The DocValuesIndexFieldData builder is a bit funky; instantiated by itself it returns a sortedSetDV, invoked with numericType() it returns a sortedNumericDV, with scriptFunction it returns a sortedSet with the script. And there's a catch-all override for special binary DVs. None of this is very builder'y since the parameters are mutually exclusive, and it's really just a thin wrapper for constructing DVs.

It might be simpler to replace this with a set of static helper methods that callers can use to generate DVs and ditch the builder model.

Separate XContent serialization from reduce logic?

Some classes, like agg buckets, combine both xcontent serialization and reduction logic. This leads to very large classes, and is a confusing mixture of concerns. Is it possible to separate this? Is it a good idea?

Allow aggs to "see" up the tree?

Aggs are isolated by design, and only know about their direct sub-aggs (and only in a limited manner). If aggs could look up the tree, it would open up new agg possibilities. And it would likely help with the pipeline agg refactoring. This would add complexity, and the isolation helps keep everything simple/composable.

[elasticmachine]

Pinging @elastic/es-analytics-geo

[polyfractal]

Procedural note: I've moved the test-related items to their own ticket: #51324

[wchaparro]

Adding team-discuss label to this meta issue to address the last three.

[nik9000]

Agg boilerplate simplification.

Aggregations require a lot of boilerplate. Most aggregations will require a Builder, Aggregator, AggregatorFactory, result interface, parsed result interface and Internal result object. Simplifying this would make it easier to develop new aggs and collapse the agg package considerably

I think most of what's left on this one is #82273.

[imotov]

I moved "Allow aggs to "see" up the tree" into its own issue #82290. This was the last outstanding issue in this meta issue, so we can now close it.