Fix sorting terms by cardinality agg

[nik9000]

The cardinality agg delays calculating stuff until just before it is
needed. Before #64016 it used the postCollect phase to do this work
which was perfect for the terms agg but we decided that postCollect
was dangerous because some aggs, notably the parent and child aggs
need to know which children to build and they can't during
postCollect. After #64016 we built the cardinality agg results when we
built the buckets. But we if you sort on the cardinality agg then you
need to do the postCollect stuff in order to know which buckets
to build! So you have a chicken and egg problem. Sort of.

This change splits the difference by running the delayed cardinality agg
stuff as soon as you either try to build the buckets or read the
cardinality for use with sorting. This works, but is a little janky and
feels wrong. It feels like we could make a structural fix to the way we
read metric values from aggs before building the buckets that would make
this sort of bug much more difficult to cause. But any sort of solution
to this is a larger structural change. So this fixes the bug in the
quick and janky way and we hope to do a more structural fix to the way
we read metrics soon.

Closes #67782

[elasticmachine]

Pinging @elastic/es-analytics-geo (Team:Analytics)

[imotov]

As you mentioned in the comment for this PR it feels quite fragile. I would be ok with temporary fixing it this way, but I would feel much better about it if we captured our "hope to do a more structural fix to the way we read metrics soon" in form of an issue and at least put it on a roadmap or better on the top of somebody's todo list. I am only starting to look into #66876 and I am not sure if fixing #66876 will result in re-introduction of "proper" and non dangerous postCollect phase, but I would rather have a duplicate ticket than drop this on the floor.

[nik9000]

I would feel much better about it if we captured our "hope to do a more structural fix to the way we read metrics soon" in form of an issue and at least put it on a roadmap or better on the top of somebody's todo list. I am only starting to look into #66876 and I am not sure if fixing #66876 will result in re-introduction of "proper" and non dangerous postCollect phase, but I would rather have a duplicate ticket than drop this on the floor.

Makes sense to me. I was thinking of making the metric method make some kind of "reader" and building the reader would kind of "flush" everything. But I admit I don't know the right way. I'll file an issue, yeah.

[nik9000]

I opened #67852.

[iverase]

I agree with Igor in the hope that we can try to fix this in a structural way in a later iteration.
My idea is that calling metrics(long owningBucketOrd) should throw an error if the sketch is not finished.

For the time being, I am ok with this approach.