workaround mongodb bug in _get_samples_bytes()

[swheaton]

What changes are proposed in this pull request?

Closes #2836 where SampleCollection.stats() was being reported as the full document size total even if a SelectField stage was present.

This bug was due to a change in behavior of $bsonSize within a $group stage after MongoDB ~ 5.2. It's believed because of the usage of the Slot Based Execution query engine for $group stage in 5.2.
A MongoDB bug ticket has been filed but that's about all we can do since there appears to be no way to turn off the SDE engine selectively.

The workaround is to grab document sizes first then sum them, in 2 stages instead of 1. This may be slightly more inefficient but likely not by much.

How is this patch tested? If it is not, please explain why.

Added unit test exposing bug in MongoDB >= 5.2. Passes now.

# connect to MongoDB 6.0.X ...
import fiftyone.zoo as foz
dataset=foz.load_zoo_dataset('quickstart')

def get_stats(collection):
    return collection.stats()["total_bytes"]

select_view = dataset.select_fields()
select_view2 = dataset.select_fields("uniqueness")
select_view3 = dataset.select_fields(["uniqueness", "ground_truth"])
assert get_stats(select_view) < get_stats(select_view2) < get_stats(select_view3) < get_stats(dataset)

Release Notes

Is this a user-facing change that should be mentioned in the release notes?

• No. You can skip the rest of this section.
• Yes. Give a description of this change to be included in the release
  notes for FiftyOne users.

What areas of FiftyOne does this PR affect?

• App: FiftyOne application changes
• Build: Build and test infrastructure changes
• Core: Core fiftyone Python library changes
• Documentation: FiftyOne documentation changes
• Other

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.03 🎉

Comparison is base (e64541e) 61.87% compared to head (3c416bf) 61.90%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2840      +/-   ##
===========================================
+ Coverage    61.87%   61.90%   +0.03%     
===========================================
  Files          259      259              
  Lines        43686    43721      +35     
  Branches       350      350              
===========================================
+ Hits         27030    27065      +35     
  Misses       16656    16656              

Flag	Coverage Δ
app	48.61% <ø> (ø)
python	99.42% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
tests/unittests/view_tests.py	99.86% <100.00%> (+<0.01%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[brimoor]

LGTM, thanks for getting to the bottom of this! 🥇

Left one small suggestion for your consideration

[kaixi-wang]

Did some reading on slot based execution, and it's possible this is the expected behavior.

Previous engine outputted documents at each stage, so $$ROOT would refer to the document of the projected fields in that stage, but with slot based, the $$ROOT is now the original document (no intermediate document created)

Hey! Query Execution engineer here, my team and I are working on SBE. Currently, query execution engine works in terms of documents. For example, in the aggregation language, every stage produces a document to be consumed by the next stage. SBE goes one step lower in abstraction layers and works in terms of values. Aggregation stages executed through SBE pass values to each other directly, without extra document materialization. This allows us to avoid many unnecessary computations and execute queries faster. As of now, we only use SBE for certain queries with $group and $lookup, but the intent is to use it across the board in the future.
https://www.reddit.com/r/mongodb/comments/v7uaso/what_does_the_slotbased_query_execution_engine_do/

[swheaton]

An execution engine should not change functionality unless documented (it is not), so either way it is a bug IMO.
They may come back (if at all) and say yeah not gonna change that. In which case their documented way of getting total document size is just broken