Improve debugging discoverability

[KangxuanYe]

For more information about how to contribute to this repo, visit this page.

Description

This is a PR to improve developers debugging experience.

In the past, developers need to turn on client logging following this document so that they can see the logs after app gets refreshed. It will request developers to select correct iframe, set verbose log level, type localStorage.debug = 'teamsJs.*' in console and then refresh the app to get logs from debugger.

With this PR, developers only need to set log level in browser as 'verbose' to see logs displayed by debugger. And they can write code as logger.turnOnDebugLogs() and logger.turnOffDebugLogs() to display the logs from debugger in a segment of code they are interested in.

One of use will be put logger.turnOnDebugLogs() before app.initialize() API call so that all of logs during initialization will be displayed on browser console.

logger.turnOnDebugLogs() and logger.turnOffDebugLogs() are to set a global variable to be true and false. With this global value, we created a wrapper over original debugger from debug npm library as topLevelLogger. If developers keep following our wiki, it will work as it is and we use debugger directly to display logs. Otherwise, if developers use API call to turn on debug logs, we call console.timeLog to display logs.

However, the experience of developers will be the same!

Main changes in the PR:

1. Created a logger capability to turn on and off console logs by leveraging on global variable.
2. Created logger capability in test app for testing purpose
3. Created a function to wrap debugger in telemetry.ts

Validation

Validation performed:

1. Please read PR description and run the test app for try out.

Unit Tests added: No

End-to-end tests added: No

[TrevorJoelHarris]

This is cool and it will probably need a good dose of explanatory comments

[KangxuanYe]

Could you please take a look on comments? Basically I just explained the code in detail.

[AE-MS]

This looks neat -- can you say more about the use-case for it? Is it something we expect customers might find easier to enable than the current set of logging steps? Or is it something you expect to be able to use when debugging issues? Etc.?

[KangxuanYe]

This looks neat -- can you say more about the use-case for it? Is it something we expect customers might find easier to enable than the current set of logging steps? Or is it something you expect to be able to use when debugging issues? Etc.?

Based on our discussion with Saurabh, I think the use-case would be customers find the bug/error/failure in their code from Teams-Js library and they wish to know what happened. Then they can read the documentation of Logger capability and by calling APIs in their codebase, they can get all/partial of client debugging loggings depending on where they turn on the client debugging loggings. In this scenario, I think customers will have easier steps for debugging and have more control on which part they would like to focus on. They can use this method for debugging but for my work, I would still request them to follow the steps we have right now to make sure they send ALL of client loggings to me from the beginning of initialization.

[KangxuanYe]

Need to turn it back to draft again because after rebasing on main, the console log complains that it cannot find timer, which is used by console.timeLog.