When testing SERVER-54221 we realized that if the gTimeseriesBucketMaxCount is significantly larger than the actual bucket counts we will exhaust the kMaxAttempt to get a non-duplicate document and fail the query.

This behavior is not ideal. We should implement a fall-back mechanism when this is the case. Two ideas discussed is to figure out if we can cheaply compute the maximum bucket count, or use a trial stage to see if we are able to sample the collection, and if not fallback to topk sorting.