BUG: Groupby min/max with nullable dtypes
- [x] closes #41743
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry

asvs show no change for non-nullable dtypes
> not really thrilled with this expansion, but i guess its needed.

I'd be OK with _not_ special-casing MaskedArray all throughout the codebase. can u refresh with some places where we special case now? > can u refresh with some places where we special case now?

array_algos.quantile, GroupBy._bool_agg, GroupBy._get_cythonized_result, WrappedCythonOp._masked_ea_wrap_cython_operation, and a bunch prospectively in #42838, #39133, #37493 small naming comments & if you can rebase just rebased; what did you think of the compromise naming of `result_mask`? > just rebased; what did you think of the compromise naming of `result_mask`?

cool with that

one place where need to update i think > one place where need to update i think

my thought with "result_mask" was to make a change in "mask" unnecessary.  im not wild about mask_in bc it is awkward in cases without mask_out > > one place where need to update i think
> 
> my thought with "result_mask" was to make a change in "mask" unnecessary. im not wild about mask_in bc it is awkward in cases without mask_out

right result_mask is fine, its the plain mask (when we also have mask_out) that bothers me. just need consistent naming. > right result_mask is fine, its the plain mask (when we also have mask_out) that bothers me. just need consistent naming.

"result_mask" is the alternative to "mask_out", so there is no more "mask_out".  I don't like "mask_in" bc we'll end up with some functions that call it "mask_in" and others that call the same thing "mask" (bc those functions dont have result_mask/mask_out) > but it might be good to add a benchmark for this

good idea.  will do as follow-up, as im hoping we can get this in quick-ish > I agree with Brock on having consistent use of mask being better than some mask and some mask_in. I think having a function here with both mask and result_mask, I think it's clear that mask is about the input.


I am cool with the names, just want to be consistent across the code base on these names / meaning > I am cool with the names, just want to be consistent across the code base on these names / meaning

What Joris and I are saying is that this _is_ the best way to be consistent w/r/t naming also in followon should validate first/last (and maybe others) are correctly handling these dtypes, can you create an issue.