MAINT: Replace use of pytest.warns(None) with warnings.catch_warnings

[WarrenWeckesser]

The use of pytest.warns(None) is deprecated in pytest 7.0.0.
The alternative suggested by the deprecation warning, pytest.warns(),
does not match the old behavior. In fact, pytest.warns() is intended
specifically to raise an error if the code in the context does not raise
the given warning, and in pytest 7.0.0rc1, the default warning used by
pytest.warns() is the generic Warning class.

This issue is discussed in the following pytest issues:

• Improve pytest.warns() docs to clarify difference with catch_warnings() pytest-dev/pytest#9002
• [prerelease] pytest.warns() doesn't seem to work properly for coverage.py pytest-dev/pytest#9386

There, the recommended alternative is to use warnings.catch_warnings.
That is the change made here.

Closes gh-15186

[WarrenWeckesser]

This fixes the last pytest-related failure in the Azure scipy.scipy (Main prerelease_deps_coverage_64bit_blas) check that I described in #15176 (comment).

There is a new failure in that check that is unrelated to this pull request. That failure is fixed by #15194.

[rlucas7]

@WarrenWeckesser

Note: I was a little confused by one of the error message
but it looks like this is the default behavior for azure, according to this, azure passing a SIGINT and falls back to a SIGBREAK if SIGINT doesn't get the job to stop. That is what appears to be happening in one of the failures. The message to stdout is not indicative of what's going on but it appears to be a timeout issue. I'm not sure if that is something commonly happening but appears unrelated.

I looked at the docs for the warnings.catch_warnings here it mentioned this isn't threadsafe. I don't see threads being used directly in the two modules but I'm not sure about some of the repo level tooling, is that going to cause undefined behavior w/threads in these two tests?

everything else in this looks fine.

[rgommers]

Thanks @WarrenWeckesser. Let me just merge this to get rid of the warning. I'll comment on the related issue.

[WarrenWeckesser]

@rlucas7 wrote

I looked at the docs for the warnings.catch_warnings here it mentioned this isn't threadsafe.

Thanks--yeah, I'm aware of that, it is an old problem. I don't know if the lack of thread safety for warnings.catch_warnings affects our tests. The reasons I'm OK with the change here is (1) we already use warning.catch_warnings elsewhere in the tests, and (2) behind the scenes, pytest.warns uses a class called WarningsRecorder that is a subclass of warning.catch_warnings, so apparently pytest.warns is not thread-safe either.