REGR: groupby doesn't identify null values when sort=False
- [x] closes #48506 (Replace xxxx with the Github issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

No whatsnew since this regression was introduced in 1.5.0. This same change will also allow us to go forward with the cleanup in #48477 as it will no longer change behavior. I've also made sure the added test passes on 1.4.x.
Thanks @rhshadrach  cc @rhshadrach This caused a couple of regressions, e.g. https://asv-runner.github.io/asv-collection/pandas/#algorithms.Hashing.time_series_string

Not sure if this was slower before, because history is missing a bit obviously Thanks @phofl - on my machine I'm seeing 2.3ms for the line `null_mask = isna(values)` whereas the whole added code is 2.58ms. My machine is likely a bit faster than the benchmark machine, so I believe this line is where most of the regression occurred. That many of the regressions don't involve null values confirms this.

I don't see a way around this op in general nor to speed it up - we could try to funnel the null values directly on the uniques / codes after factorize, but that seems like a bad idea and would only help when there aren't a lot of distinct values.

However, we should only need to perform the op when sort is False and dropna is False. I'll confirm that and post a new fix moving this upstream so we can avoid it at least some of the time.