Put framework logging into LOGGING and fix import resetting logging

[antonymilne]

Description

Fixes #1558. Fixes Windows CI problem in #1592.

Also changed conf_logging to logging_config in a few places for consistency.

Development notes

This has been quite a journey, but after many, many different attempts at this I think I've now got a good solution 😬

Before:

• framework-side logging was not being passed to the parallel runner in certain cases (when subprocess is spawned, which means on Windows (all Python versions) and macOS (Python 3.8+) - see Get parallel runner to recognise framework-side logging config #1558 for details)
• a very mysterious bug was breaking Windows e2e tests involving parallel runner and a plugin in [KED-3023] Enable plugins to extend starter-aliases default list #1592
• LOGGING global variable was used to pass logging to spawned subprocesses

Now:

• LOGGING global variable still exists (there's no good way to get rid of it) but is now set to load framework default logging config initially and then gets overwritten with project logging config. The mechanism for this is a new _ProjectLogging class, which makes logging configuration much closer to how we configure other things in the same file
• we no longer rely on the side-effect of importing kedro.config.default_logger to load setup framework logging config
• in fact, we now no longer need this file. What it's doing fits in better in project.__init__.py anyway, so I've removed it
• this is a very slight breaking change, because there's a small chance someone currently does import kedro.config.default_logger, which will no longer work. I checked on #kedro-users and discord and no one is knowingly doing this. The only case I can think of someone doing this would be from copy and pasting our current ipython extension script into a script of their own. This itself is quite unlikely, but if it is the case then it's comparable to very small breaking changes to non-essential workflows that we've put into minor releases before, so both Ivan and I are ok with this

Cause of Windows e2e test failures in #1592

This was very subtle and mysterious so let me document it here. The error was nothing to do with rich but actually a result of an import in a plugin!

• test_plugin did from kedro.framework.cli.starters import ...
• by Python's import mechanism, this imports in turn kedro.framework.cli ➡️ kedro.framework.main (due to __init__.py import) ➡️ import kedro.config.default_logger
• this reset the logging mechanism partway through a spawned subprocess, which messed up the logging
  Now that there's no logging side-effects on file import this is not a problem.

Testing

Tested manually all the following cases:

• kedro run with and without project logging.yml, with and without plugin with imports
• kedro run --runner=ParallelRunner with and without project logging.yml, with and without plugin with imports
• the above with a packaged project
• kedro ipython and kedro jupyter lab
• throwing exception inside a node

Checklist

• Read the contributing guidelines
• Opened this PR as a 'Draft Pull Request' if it is work-in-progress
• Updated the documentation to reflect the code changes
• Added a description of this change in the RELEASE.md file
• Added tests to cover my changes

[antonymilne]

The major success here is that this now acts like pipelines and settings, and configure_logging is much more analogous to configure_project than it used to be.

[noklam]

https://kedro.readthedocs.io/en/latest/search.html?q=rich&check_keywords=yes&area=default

We have the option to opt out from Rich logging, but do we have the option to opt out from the Rich traceback?

[antonymilne]

Yes, though not as easily as with configuring logging. You can do sys.excepthook = sys.__excepthook__ to change the traceback handler back to Python's default one. We haven't documented this anywhere yet because it's a bit obscure and not totally obvious where the best place to put that code would be, so I was planning to wait to see if any user asked it first 😅

[noklam]

Awesome! Amazing work that fixes the very subtle bug and I like the more consistent _ProjectLogging

[SajidAlamQB]

Awesome work, this looks perfect thank you! 🌟