--[BE Week] Minimize logging spam

[jturner65]

Motivation and Context

The default logging behavior in habitat-sim has been overwhelming for some time now. So much debug information is displayed to the console that any important warnings or errors get lost in the noise. This PR is intended to address this issue.

Habitat-sim supports 4 logging levels : VERY_VERBOSE, DEBUG, WARNING and ERROR. The intended purpose of these logging level messages is as follows :

• ERROR means some action or process has failed that the user needs to be aware of.
• WARNING means that although a process didn't outright fail, it may be yielding an unexpected/inappropriate result that the user should take note of.
• DEBUG means "here's the result of a process"
• VERY_VERBOSE means "here's the result of a process with in-depth explanation".

This PR is geared toward making adjustments to the logging behavior of habitat-sim in order to make console output less overwhelming and more useful. The main changes are as follows :

1. Currently Habitat-Sim sets the logging level by default to be DEBUG. This level is inappropriate for general use of the simulator, and is the primary culprit for information overload. This PR sets the default logging level to WARNING instead.
2. Many messages in the assets, physics and metadata subsystems got demoted from warning to debug.

NOTE : Users can still modify their logging level to get more or fewer messages from the simulator by following the guidelines on this page.

To give an idea of the changes in this PR, before this PR's changes, loading a Floorplanner scene would yield over 45k messages to the console. With the changes in this PR, loading the same scene now prints 4 messasges. Note : all of the information -can- still be printed to the console if desired (if hunting down a bug, for instance) but the user would have to specify a more verbose logging level as in the instructions here.

How Has This Been Tested

C++ and python tests pass. The logging test needed to be slightly modified.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have completed my CLA (see CONTRIBUTING)
• I have added tests to cover my changes.
• All new and existing tests passed.

[0mdc]

Awesome! Thanks for tackling this!

[eundersander]

LGTM!

[eundersander]

*convenience

[0mdc]

LGTM!