Fix logs still appearing even when LogLevel is set to none bug

[RubenCerna2079]

Why make this change?

• Closes issue [Bug]: Startup class logger is not properly initialized #3262
  The logger for the Startup class is not initialized properly, since this logger is special due to the nature of the Startup class it needs to be continuously updated as DAB initializes. This causes two problems:

  • Some logs appear even when LogLevel is set to some value that would impede those logs to appear.
  • Some logs don't appear at all, even when LogLevel is set to a value that should allow them to be logged.

• Closes issue [Bug]: CLI logs being outputed even after LogLevel is set to none #3256 & [Bug]: log-level seems like it is not working when two in config. #3255
  The CLI logger still outputs some logs even when the LogLevel is set to none. It is expected that if the LogLevel set is none or some other level that shouldn't output the information level, the logs will not appear.

What is this change?

In order to solve issue #3262:

• We removed the LogBuffer from the services inside of Startup.cs, this is necessary since we wanted each class to have its own LogBuffer so that we are able to tell from which logger the logs are being outputted.
• Then, we also correctly initialized the Startup logger by changing the method that it was using to initialize the logger, it now uses CreateLoggerFactoryForHostedAndNonHostedScenario which checks if there are any LogLevel namespaces from the config file that can be applicable for the specific logger. It is important to note that there are multiple places where the logs are flushed in order to cover for the cases in which an exception is found and causes DAB to end abruptly, and when we there is an IsLateConfigured scenario.
• We also changed the logger for the LogBuffer in all the missing places where it creates logs before the logger is able to properly initialize to add those logs to the LogBuffer and only flush them after the loggers are initialized.

In order to solve issue #3256 & #3255:

• We changed the CLI so that we add all the logs go to a single global LogBuffer that is created inside the StartOptions.cs until it is able to deserialize the RuntimeConfig and find which level to set the LogLevel in order to flush all the logs.
• This is something that we only want to happen when we use the dab start command, which is why we only make this change in the StartOptions.cs file, on the function TryStartEngineWithOptions inside of ConfigGenerator.cs, and a few functions from Utils.cs and ConfigMerger.cs that are used inside the TryStartEngine function.

How was this tested?

• Integration Tests
• Unit Tests

Sample Request(s)

• dab start --LogLevel none
• dab start --LogLevel error

[RubenCerna2079]

/azp run

[RubenCerna2079]

/azp run

[RubenCerna2079]

/azp run

[Aniruddh25]

Not clear how using different LogBuffer is helping to fix CLI logs being outputed even after LogLevel is set to None.

[Aniruddh25]

Why do we need this helper method? The caller is anyway passing both the logger and the logbuffer to this function. Its not like the caller is unaware, if the CliBuffer is null or not, if its a static member that you initialize then it is always going to be valid. You can simply call the BufferLog in the caller itself.

[RubenCerna2079]

There are some places where we use it where it is not always necessary as the loggers have already been initialized properly, so we pass the LogBuffer as a null so that it directly logs the message. I will also add this to the description to make it easier to understand.

[Aniruddh25]

In those other callers, where the logger directly logs - you can simply use logger.Log. There you dont need the buffer.

This wrapper is unnecessary, we can simply either flush to buffer or do logger.log in the respective callers.
That way, its easier to read as well - otherwise, in the various callers - the reader is unaware what is going to happen unless they look into the function definition.

[Aniruddh25]

For the CLI we first check if the LogBuffer is null, to see if we need to save the log inside the buffer or send directly through the logger, we do this since some of the functions that are used before the loggers are initialized are also used after the logger initialization, so we need a way to ensure that the logs aren't saved after we flush the logger as we are not expecting to use it anymore, which means the logs would be lost.

I do not understand this.

[Aniruddh25]

If we use different LogBuffers for different classes, wouldn't the logs get out of place as we will be flushing the log buffers in a different order of collecting the logs.

[Aniruddh25]

Why does the description say we want to fix logs only from dab start? Why not the other commands?