logging library refactor / update where needed

[jayunit100]

If we dont want to change logging libraries, i guess just a quick audit of where we use what library, can be a good conclusion to this issue. Otherwise, this could hit 100s of files so... lets make sure we think it through.

This is not a cosmetic issue: TF builds can take a while cumulatively, and we run them 100s of times a day, so how we log the timing of steps is important.

....

Bug description

Recently we got some non-machine readable logs while optimizing framework:

 �$ /usr/local/go/bin/go mod download

and along the way, we realized we had a old, largely unmaintained library for our logging: github.com/aunum/log.

We have a PR to make those logs more readable #4183 w/o requiring emojis, but... the question of: what logging librarys we should use, where, for all of the framework components needs to be resolved...

... OTHERWISE one of these bad things can happen ...

• new colored or emoji logs might pop up in places where we dont want them (backend build systems)....
• or the opposite: we might use klog in user facing environments...

Solution

• GENERAL
  • we need to get rid of unmaintained logging libs.
• USER FACING (i.e. tanzu cluster create)
  • use a maintained logger for user facing commands (https://github.com/sirupsen/logrus)?
  • user facing commands should support spinning wheels and colors
  • whatever we do, we shouldnt have user facing logs as json
• NON USER FACING (i.e. make cli)
  • non-user facing commands dont need to support spinning wheels and colors

Affected product area (please put an X in all that apply)

• ( ) APIs
• ( ) Addons
• ( x ) CLI
• ( ) Docs
• ( ) IAM
• ( ) Installation
• ( ) Plugin
• ( ) Security
• ( ) Test and Release
• ( ) User Experience
• (x ) Developer Experience

Expected behavior

Steps to reproduce the bug

Version (include the SHA if the version is not obvious)

Environment where the bug was observed (cloud, OS, etc)

Relevant Debug Output (Logs, manifests, etc)