Use setLevel instead of setting logger.level directly

Python 3.7 added caching of the log level for calls to isEnabledFor
on a logger[0]. As a result, modifying the logger level directly
can cause a mismatch in behavior if a log call was made prior to
that modification. In our case, we were calling logger.info before
the info level was enabled, which meant the logger cached the fact
that it was not enabled for info-level logging. Even after setting
the level to NOTSET, it was still remembering that it shouldn't log
info messages and that breaks our unit tests on py37. There is a
related issue open against Python[1], but basically the answer there
was "don't mess with logger internals".

The simple fix is to use logger.setLevel for resetting the log level
instead of modifying the attribute directly.

Change-Id: Ifd1300d8e4280df1913f632e964f9458dbb2db55
0: 78c18a9b9a (diff-5bd69232a06838f179312d3e48ccf506)
1: https://bugs.python.org/issue34269
Closes-Bug: 1783630

oslo_log/log.py

@@ -226,7 +226,7 @@ def _load_log_config(log_config_append):
             # Reset all existing loggers before reloading config as fileConfig
             # does not reset non-child loggers.
             for logger in _iter_loggers():
-                logger.level = logging.NOTSET
+                logger.setLevel(logging.NOTSET)
                 logger.handlers = []
                 logger.propagate = 1
             logging.config.fileConfig(log_config_append,