Generalize seelog config and add setters

[timj-hh]

Summary

This change generalizes the Seelog/global logger configuration. Currently, the timestamp format is hardcoded in, and it is unwieldy to change values such as the default output file, log format, etc. by hand as they are controlled by environment variables, and a logger Config struct.

Implementation details

• Adds a new timestampFormat field into the private logger Config struct. This will specify the timestamp format used by structured loggers (i.e. RFC 3339). A new default has been added to the value used in agent module, so there is no functional change introduced. Custom formatters now consume this Config attribute rather than the direct time format.
• New setter functions have been added to modify the Config struct for consumer facing logger config
• SetTimestampFormat: Set the logger timestamp format. time.Format() will accept a time format struct, or something custom such as SetConfigLogFile.
• SetConfigMaxFileSizeMB: Set the max file size of the logger before log rotation
• SetConfigLogFormat: Set the format for logging(logfmt or json)
• SetConfigLogFile: Set the output file for logging.

Testing

New tests cover the changes: yes

TestLogfmtFormat_Structured_Timestamp and TestJSONFormat_Structured_Timestamp have been introduced to test the ability to pass a custom time format. They will validate the correctness of a custom time format passed in. Existing tests verify that timestamp format remains consistent when untouched.

Description for the changelog

Generalize seelog config and add setters

Does this PR include breaking model changes? If so, Have you added transformation functions?
No. Most of this PR adds setters, and what was abstracted has been replaced with a default used by the agent module.

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[JoseVillalta]

LGTM

[amogh09]

The existing SetLevel function takes care of reloading the seelog config but the new setter functions do not. I understand that now there are multiple setter functions, and a user might want to call the setter functions and then trigger a (re)load manually by calling InitSeeLog once but this breaks the current pattern that setter functions take care of reloading the configuration.

[amogh09]

Why not make the new setter functions call reloadConfig?

[amogh09]

Discussed offline that reloadConfig doesn't help with reloading log format.

[timj-hh]

Synced offline, Some setters will require a reload of the custom formatters, which is not something reloadConfig does. If we are always calling InitSeeLog after each setter anyways, the access pattern can be abstracted to call InitSeeLog manually after modifying desired config attributes

[amogh09]

Let's update the descriptions of the new setter functions to say that InitSeeLog needs to be called for the change to take effect.

[amogh09]

Can be done in a new PR.