Rebalance debug logging

We do have a serious mess with the debug messages. This is a topic that has been signaled on several occasions, with people asking and getting confused in general. Here's a couple pointers:

• see #1916 (closed) for specific customer complaint
• packet drops used to be logged on many levels
• we currently use levels 0, 10, 15, (no 20 or 30), 40, 45, 50 and 55
• the documentation incorrectly states that the debuglevel goes to 99 (the actual value configured can be larger, the highest value we use is 55)
• it is impossible for the user to figure out a logging level of a given message, even if looking at the code. The level constants are defined in .h file, but defined in .cc, then in many cases not used directly, but used to set up other const values that are used. This is not a programming logic an average sysadmin is willing to follow.
  • Done in #1723 (closed). The log level is now under each debug message in .mes files and in the ARM.
• there should be an ability to log the debuglevel similar to loglevel in the logs.
• there should be a way to update the messages doc with the actual debug levels being used. Some sort of a maintenance script could do that. We have tools/reorder_message_file.py. Perhaps we could extend it to do something extra for us?
  • Done in #1723 (closed). The script is ./tools/check-messages.py --autofix.
• DBGLVL_COMMAND_DATA (20) is defined, but not used anywhere
  • It is. For 7 messages in src/hooks/dhcp/lease_cmds/lease_cmds_messages.mes.
• no debug level is defined for 30

This is definitely post 2.0 topic.

Update: RT23820 opened for this.