[v7r2] Make subLogger more flexible

[aldbr]

In response to: #4524

This PR makes gLogger more "flexible":

• Use the logging level as it should be used*
• The level of the Backend objects can now be set in the configuration
• Possibility to set the level of the subloggers
• Possibility to set the log record format of the sublogger (showHeaders() and showThreadIDs())
• Two new methods to change the log record format:
  • showTimeStamps(): display or hide the timestamp
  • showContexts(): display or hide the component and the logger name
• No more need to create a custom Formatter to wrap a Formatter just to use it in a backend
• Deprecated methods have been deleted
• Tests have been extended and are now made for pytest
• Documentation has also been updated

BEGINRELEASENOTES
*FrameworkSystem
NEW: new methods to change the log record format: showTimeStamps and showContexts
CHANGE: make gLogger more flexible: level and format options can be set by subloggers
ENDRELEASENOTES

*About the level change:

The level is currently managed in a strange way:

• the logger level is always debug
• Logging.setLevel() just change the level of the Backends (so of the handlers) attached to the Logging

This was done in order to make sure that the centralized logging could not be disabled: all logs from all Logging objects go to a MessageQueue for instance.
In practice, subloggers don't have any Backend and just propagate the logs to LoggingRoot that spreads the logs across its Backends.
Thus, Logging.setLevel() has no effect from a sublogger.

In this PR, the Logging level is attached to the logger level to better respect the standard mechanism:

• Logging.setLevel() works from every sublogger and change the level of its underlying logger
• Backend level can still be changed from the configuration to only allow log records from a certain level

This means that the centralized logging can only get logs that respects the following condition: log record level > logger level:

• the lower the Logging level, the more logs you will get in the centralized logging system
• to only get logs from a certain level in a specific Backend, make sure to set its LogLevel in the configuration

[fstagni]

This is IMHO ok.

[andresailer]

some comments for tests and docstrings.

[chaen]

(from what I gather from private discussion) To make things very clear (@aldbr you should state that in the PR description), this means that there would be no way anymore (and rightly so) to set two backend to gLogger (say, stdout and logstash) and have the stdout running in level INFO while logstash runs DEBUG. Correct ?

[aldbr]

(from what I gather from private discussion) To make things very clear (@aldbr you should state that in the PR description), this means that there would be no way anymore (and rightly so) to set two backend to gLogger (say, stdout and logstash) and have the stdout running in level INFO while logstash runs DEBUG. Correct ?

Alright, I've just added a comment about the level at the end of the PR description.

Well, yes and no.
You can still set the Backend level from the configuration, but it doesn't mean that you are going to get all the logs from this level.
For instance, let's say stdout level is INFO and logstash one is DEBUG:

logger.setLevel('notice')
logger.debug('message')

# stdout

# logstash

The log record 'message' is blocked at the Logging (logger) level because DEBUG < NOTICE and will not appear in the Backends.

logger.setLevel('debug')
logger.debug('message')

# stdout

# logstash
message

Here the log record is not blocked by the Logging because DEBUG = DEBUG, and can go the Backends (handler):

• In stdout: DEBUG < INFO, the log record will not appear
• In logstash: DEBUG = DEBUG, the log record will appear

Is it clear?

[chaen]

I am happy if this goes to v7r1, since we (LHCb) will run more hackaton with it. But I believe FranceGrille (@atsareg) and GridPP (@marianne013 ) are already quite ahead with the use of v7r1, so it's only fair if they decide if it can go or not.

[marianne013]

We are only running v7r1 in pre-prod, but please don't break it any more than it already is.

[chaen]

@marianne013 😆 So that means v7r2 ? Fair enough.

[fstagni]

@aldbr can you please rebase to v7r2? Then this can be approved and merged.

[atsareg]

Please, rebase on the current integration branch

[fstagni]

I guess the test is failing because of cddf80c