Fix doFinalReduction to remove keys

[theneelshah]

Fix doFinalReduction to remove keys when post-barrier steps produce nothing. This fixes the empty keys in the output. Only the keys with values show up.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.20%. Comparing base (a28cd1f) to head (4926f93).
⚠️ Report is 179 commits behind head on master.

Files with missing lines	Patch %	Lines
...erpop/gremlin/process/traversal/step/Grouping.java	50.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3501      +/-   ##
============================================
- Coverage     76.35%   76.20%   -0.16%     
- Complexity    13424    13895     +471     
============================================
  Files          1012     1030      +18     
  Lines         60341    62762    +2421     
  Branches       7075     7350     +275     
============================================
+ Hits          46076    47830    +1754     
- Misses        11548    11956     +408     
- Partials       2717     2976     +259     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Cole-Greer]

Hi @theneelshah,

If I'm understanding the change correctly, the new behaviour somewhat contradicts the currently documented group() step semantics. These docs will need updating if we are to proceed. Could you share some extra details on what use case is motivating this change?

Also if we proceed here, I think this change likely warrants adding a new scenario to Group.feature as well as a quick CHANGELOG entry.

[Cole-Greer]

After taking a closer look and running some test queries in this branch, I think I misunderstood the scope of this change. It's more narrow than I previously thought and I no longer think it's in violation of the documented semantics. I now understand it to be a bug fix for a specific edge case.

// 3.8.1
gremlin> g.V().group().by("name").by("age")
==>[ripple:[],peter:[35],vadas:[27],josh:[32],lop:[],marko:[29]]
gremlin> g.V().group().by(values("name")).by(values("age"))
==>[peter:35,vadas:27,josh:32,marko:29]
gremlin> g.V().group().by(values("name")).by(values("age").fold().unfold())
==>[ripple:[],peter:[35],vadas:[27],josh:[32],lop:[],marko:[29]]

// This Branch
gremlin> g.V().group().by("name").by("age")
==>[ripple:[],peter:[35],vadas:[27],josh:[32],lop:[],marko:[29]]
gremlin> g.V().group().by(values("name")).by(values("age"))
==>[peter:35,vadas:27,josh:32,marko:29]
gremlin> g.V().group().by(values("name")).by(values("age").fold().unfold())
==>[peter:35,vadas:27,josh:32,marko:29]

I no longer think any docs changes are warranted here, I think all that is needed is a feature test for g.V().group().by(values("name")).by(values("age").fold().unfold()) (or something less contrived than my fold().unfold() if you have something like that), as well as a quick changelog entry.