Description

Fixes #20005.

import astropy can fail outright with a LoggingError when another library has
replaced warnings.showwarning (or sys.excepthook) after Astropy installed its
own handler. This bites pytest-cov users in particular — the coverage plugin
installs its own showwarning, and then any package that imports Astropy at
collection time (the issue came in from astroquery.mast) crashes on import:

astropy/logger.py:498: in _set_defaults
    self.disable_warnings_logging()
astropy/logger.py:278: in disable_warnings_logging
    raise LoggingError(
E   astropy.logger.LoggingError: Cannot disable warnings logging: warnings.showwarning
    was not set by this logger, or has been overridden

Root cause. _init_log() runs at import time and calls
AstropyLogger._set_defaults(), which resets any previously installed hooks by
calling disable_warnings_logging() / disable_exception_logging(). Those
methods deliberately raise LoggingError when warnings.showwarning /
sys.excepthook no longer points at Astropy's handler — a sensible contract for a
direct caller, but fatal here, because _set_defaults() is a best-effort reset
that runs unconditionally during import astropy.

Fix. Make the import-time reset tolerant: _set_defaults() now catches the
LoggingError from the two disable calls, leaves the third-party hook in place
(it never clobbers someone else's showwarning/excepthook), and just clears
Astropy's own bookkeeping so the logger returns to a clean state. The public
disable_warnings_logging() / disable_exception_logging() API is unchanged —
they still raise for direct callers, so the existing contract tests
(test_warnings_logging_overridden, test_exception_logging_overridden) still
pass. Because conf.log_warnings defaults to True, _set_defaults() then
re-installs Astropy's own handler on top and records the third party's hook as the
recoverable original, so warning capture keeps working and the other library's
hook is restored if Astropy is later disabled.

I fixed both the showwarning path (the reported one) and the sibling
sys.excepthook path in the same method, since they make the identical
assumption.

How was this tested?

Reproduced the exact failure first, then confirmed the fix, on a source build of
main:

import warnings
from astropy import log
from astropy.logger import LoggingError

warnings.showwarning = lambda *a, **k: None   # stand in for pytest-cov et al.
log._set_defaults()                           # RED on main: raises LoggingError
                                              # GREEN after fix: returns cleanly

I also confirmed that with warnings.showwarning overridden before the import,
import astropy now succeeds instead of raising.

Two regression tests were added to astropy/tests/test_logger.py
(test_set_defaults_tolerates_overridden_showwarning and
test_set_defaults_tolerates_overridden_excepthook).

Full logger suite is green and lint is clean at the repo-pinned tool version:

$ python -m pytest astropy/tests/test_logger.py -q
33 passed, 1 skipped

$ ruff check astropy/logger.py astropy/tests/test_logger.py   # ruff 0.15.15
All checks passed!
$ ruff format --check astropy/logger.py astropy/tests/test_logger.py
2 files already formatted

A changelog fragment is included at docs/changes/20005.bugfix.rst (named after
the issue; happy to rename it to the PR number if preferred).