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?

Important Note: These changes currently only allow us to change the LogLevel from the CLI with the default namespace in the config file. An task was created to solve this issue: #3451

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]

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?