Revert "REF: remove unnecessary na_value fixture"
This reverts one of the four commits of https://github.com/pandas-dev/pandas/pull/54719. 

While this was certainly a logical change to make (it's superfluous for our tests), it can give problems for downstream EAs (we got several failures in the geopandas' CI with pandas nightly), if they use `None` as their missing value.

The problem is that pandas didn't really support to properly set None as the `ExtensionDtype.na_value` (see eg https://github.com/pandas-dev/pandas/issues/44602), and so we relied on the fixture to use the correct value for the tests while using the default of NaN for the attribute. 
> The problem is that pandas didn't really support to properly set None as the ExtensionDtype.na_value (see eg https://github.com/pandas-dev/pandas/issues/44602), and so we relied on the fixture to use the correct value for the tests while using the default of NaN for the attribute.

Wouldn't actually addressing this be the correct solution? Yes, certainly, and we have a two year old open issue about it. 

But nevertheless in the meantime it would be easier for downstream EAs that use None to keep the tests as they were > But nevertheless in the meantime

Is this time-sensitive?  Or just "before 2.2"?  If the latter we should take some time to try to address the underlying issue. > Is this time-sensitive? Or just "before 2.2"? If the latter we should take some time to try to address the underlying issue.

It's "time sensitive" in the sense that it is annoying that we have a bunch of failing tests on our CI build with nightly pandas. 

And I also don't see the issue with just merging this. We can easily change it back at some point when the issue is fixed (or tested, as it might already be fixed), although even then, we might want to wait a while with changing the test, as downstream EAs still test against multiple pandas versions typically. > Let's deprecate this then

Do you mean to deprecate the pytest fixture? (not fully sure how that would work) I commented on #44602; I expect the geopandas problem is subtly different Yes, the problem for geopandas is that it supports multiple pandas versions, and this was only apparently fixed in a recent version. > Yes, the problem for geopandas is that it supports multiple pandas versions, and this was only apparently fixed in a recent version.

Hmm i dont think we have a policy on the extension backward/forward compatibility of the extension tests.  Tests in general I wouldn't expect to work with anything but the matching version. This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this. > Tests in general I wouldn't expect to work with anything but the matching version.

Of course the tests only work in the matching version, and downstream EA implementation import those tests from pandas, and thus in practice only test with matching versions. 
But the issue here is not supporting the test across versions, but supporting the dtype `na_value` (i.e. https://github.com/pandas-dev/pandas/issues/44602) across pandas version. 

This PR is a very simple change, that makes the life easier for downstream testing in geopandas. So unless there is actual strong objection to do so, I am planning to merge this. > But the issue here is not supporting the test across versions, but supporting the dtype na_value (i.e. https://github.com/pandas-dev/pandas/issues/44602) across pandas version.

As I commented in #44602, that appears to be working without this kludge.  IIUC you said the geopandas use case is working too.  If geopandas wants to test against older pandas, they'll need to test against older versions of the extension tests.  I don't see any way around that.

As you say this is a small change so I don't care _that_ much.  Is there a path to getting rid of this eventually?  e.g. keep it around through 2.x and then re-remove it? > As I commented in https://github.com/pandas-dev/pandas/issues/44602, that appears to be working without this kludge. IIUC you said the geopandas use case is working too.

This is working for the latest version of pandas, but geopandas cannot yet adopt that because we support a range of pandas versions.