Preserve logs that LoggingPanel would previously overwrite

[riwatt]

This might solve the root cause of issues reported in #695 #1078 and #1300

---

Summary:
LoggingPanel upon its import, changes the Python interpreter's root logger to log into a handler that collects its records for the LoggingPanel's display. However for users that don't explicitly configure the root logger this looks like the Debug Toolbar suppresses their logs that previously went to standard error.
With this commit, the logs will still keep going to standard error even if the LoggingPanel is installed, but only if the root logger has not been explicitly configured with a handler yet.
This behavior will make it so that installing DDT won't break logging neither for users that already have logging customizations nor for users that have an out-of-the-box django default logging setup.

Also: change LOGGING config in tests/settings.py because now DDT's own test suite would show more logs without an explicit config.

[matthiask]

Thanks! Looks good.

I was wondering for a moment if it would be possible to use lastResort for the toolbar but that would probably be more brittle and less obvious.

I'm always worrying a bit about module-level configuration because of the dependency on import ordering. This will be fine though since Django initializes logging long before the toolbar is initialized for the first time in the middleware.

[tim-schilling]

Is it possible to test this in the test suite? Otherwise this looks good, but needs verification.

[riwatt]

Is it possible to test this in the test suite? Otherwise this looks good, but needs verification.

Sorry I didn't mention it, but I verified this with a minimal django app by varying its logging configs.
Would it be sufficient if I describe that repro here?
Or maybe I can add something to the example app that can show before and after behavior?

Fully covering this within the test suite might be difficult because of the above mentioned concerns of the original code overriding global behavior at import time. I will look into it though, but let me know if repro is enough.
Thanks for the quick reviews!

[matthiask]

I agree with the sentiment that adding a unittest which fully covers this may be hard to do. Maybe it's feasible to add a regression test which emits a logging message without any configured loggers and which verifies that the output appears on sys.stderr? (maybe mock stderr if necessary) I think this should cover the expected default behavior and would be sufficient.

If that proves hard to do then I think a description is fine. We're all volunteering here :)

[riwatt]

@matthiask I rebased this branch so its first commit is now a regression test.
If you run the testsuite against that commit only then it will fail, but then you can see that the final commit fixes it.
I also added my original reproducer app into this repo: https://github.com/riwatt/ddjt_logging. The readme there describes the steps I used to test the fix.

---

Re: the precommit.ci failure is because of psf/black#2964
I ran it locally with black==22.3.0 without any issues.
Edit: looks like black / precommit is fixed in #1598

[matthiask]

Thanks! Let's merge this, everything makes a lot of sense to me.