Don't store hashes in GroupOrdering

[tustvold]

Which issue does this PR close?

Closes #.

Rationale for this change

The approach of storing hashes in GroupOrdering was causing merge conflicts for #7016 and is not actually necessary

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[alamb]

Looks great to me

FYI @mustafasrepo and @ozankabak -- this effectively should improve the speed of streamed / bounded group by

[alamb]

I double checked: https://docs.rs/hashbrown/latest/hashbrown/raw/struct.RawTable.html#method.iter 👍

[alamb]

I think this is both wonderfully elegant as well as cryptic. How about some comments (this is so I don't have to refigure this out the next time I see this code):

Suggested change

	unsafe {
	for bucket in self.map.iter() {
	match bucket.as_ref().1.checked_sub(n) {
	None => self.map.erase(bucket),
	Some(sub) => bucket.as_mut().1 = sub,
	}
	}
	unsafe {
	for bucket in self.map.iter() {
	// decrement group index by n
	match bucket.as_ref().1.checked_sub(n) {
	// group index was < n, so remove from table
	None => self.map.erase(bucket),
	// group index was >= n, shift value down
	Some(sub) => bucket.as_mut().1 = sub,
	}
	}

I double checked https://docs.rs/hashbrown/latest/hashbrown/raw/struct.RawIter.html

You must not free the hash table while iterating (including via growing/shrinking).
It is fine to erase a bucket that has been yielded by the iterator.
Erasing a bucket that has not yet been yielded by the iterator may still result in the iterator yielding that bucket (unless reflect_remove is called).
It is unspecified whether an element inserted after the iterator was created will be yielded by that iterator (unless reflect_insert is called).
The order in which the iterator yields bucket is unspecified and may change in the future.

Which seems to be followed 👍