BUG: IntegerArray/FloatingArray constructors mismatched NAs
- [ ] closes #xxxx
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [x] whatsnew entry

Same yak-shaving as #44495 (which turned out to be a dead end for this particular yak, but still a perf bump)
> The setitem change / bug fix is unrelated to the constructor fix? Or it's because you are testing that through setitem as well?

The setitem bug was identified first and the cause tracked back to the constructor. ok to merge, @jorisvandenbossche comments could be afollow up (or here is ok too) Let’s do as follow up, these constructors will need plenty more work.

On Sun, Nov 21, 2021 at 3:40 PM Jeff Reback ***@***.***>
wrote:

> ok to merge, @jorisvandenbossche <https://github.com/jorisvandenbossche>
> comments could be afollow up (or here is ok too)
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/44514#issuecomment-974921157>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB5UM6HWBAVF7UB36P6IPDTUNF7O3ANCNFSM5IKC63JQ>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
 gentle ping; this is a blocker for fixing a bug in Series.where, which in turn should allow us to share some more Block methods. Two questions, but feel free to merge as well updated to raise inside is_numeric_na @jorisvandenbossche if you want to look or can merge i think comments have all been addressed here?  bugfix follow-up is ready. This seems to give a big slowdown in some benchmarks (eg 10x in https://pandas.pydata.org/speed/pandas/#groupby.Cumulative.time_frame_transform?python=3.8&Cython=0.29.24&p-dtype='Float64'&p-method='cumsum'&commits=f5107e41-12afff15). Can you take a look? Yah, looks like a lot of time is being taken in is_numeric_na.

```
from asv_bench.benchmarks.groupby import *
self = Cumulative()
self.setup("Float64", "cumsum")

%timeit self.time_frame_transform("Float64", "cumsum")

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    1.791    1.791 {built-in method builtins.exec}
        1    0.000    0.000    1.791    1.791 <string>:1(<module>)
       10    0.014    0.001    1.791    0.179 groupby.py:569(time_frame_transform)
       10    0.000    0.000    1.773    0.177 generic.py:1179(transform)
       10    0.000    0.000    1.773    0.177 groupby.py:1608(_transform)
       10    0.000    0.000    1.773    0.177 groupby.py:3117(cumsum)
       10    0.000    0.000    1.773    0.177 generic.py:1103(_cython_transform)
       10    0.000    0.000    1.762    0.176 managers.py:1266(grouped_reduce)
       50    0.000    0.000    1.762    0.035 blocks.py:381(apply)
       50    0.000    0.000    1.758    0.035 generic.py:1118(arr_func)
       50    0.000    0.000    1.758    0.035 ops.py:919(_cython_operation)
       50    0.000    0.000    1.699    0.034 ops.py:587(cython_operation)
       50    0.001    0.000    1.697    0.034 ops.py:319(_ea_wrap_cython_operation)
       50    0.000    0.000    1.559    0.031 ops.py:376(_reconstruct_ea_result)
       50    0.000    0.000    1.558    0.031 floating.py:263(_from_sequence)
       50    0.001    0.000    1.557    0.031 floating.py:85(coerce_to_array)
       50    1.551    0.031    1.551    0.031 {pandas._libs.missing.is_numeric_na}
       50    0.000    0.000    0.134    0.003 ops.py:434(_cython_op_ndim_compat)
```

Looks like we are calling is_numeric_na in cases where we have float64 dtype, so can just use np.isnan.  Should be an easy patch.
