Consistent naming of 'no-op', 'empty' aggregators

[clintropolis]

Follow up of discussion here requesting that naming of aggregators is consistent.

I am currently unsure if it is worth using naming convention to distinguish "empty" aggregators, which create an empty value to offer up for combining/merging but otherwise do nothing during aggregation, and "no-op" aggregators which do nothing and return constants for combining/merging.

Aggregators I would consider "empty":
datasketches:
ArrayOfDoublesSketchNoOpAggregator, ArrayOfDoublesSketchNoOpBufferAggregator
druid-bloom-filter:
EmptyBloomFilterAggregator, EmptyBloomFilterBufferAggregator

Aggregators I would consider "no-op"
processing:
NoopAggregator, NoopBufferAggregator
datasketches:
DoublesSketchNoOpAggregator, DoublesSketchNoOpBufferAggregator
distinct-count:
EmptyDistinctCountAggregator, EmptyDistinctCountBufferAggregator

If there is not enough distinction in behavior between what I've classed as "empty" and "no-op" then these should all share naming convention, but at minimum, they should at least be self consistent within behavior, with all "empty" classes starting with "Empty" and all "no-op" classes starting with "Noop" or something to that effect.

This needs #6397 merged first

[gianm]

I don't think there's much of a real difference. All of the classes you mentioned are doing the same kind of thing: returning empty/null placeholder objects from get and not doing anything on aggregate.

[gianm]

I would call them all "Noop" since on a row-by-row basis they are no-ops.