enhance the log init process

[Frapschen]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:

This PR addresses the following changes:

• Unify the log level flag to --log-level.
• Use a string instead of a number to represent the log level.
• Centralize the log help function into a single Go file.
• Move the logging package to /internal/telemetry/logging.

Additional thoughts on point 4: With tracing currently under proposal, we will also need a package to manage the trace SDK. I recommend placing it in /internal/telemetry/trace.

Any other suggestions for improvement are welcome! 😊

Does this PR introduce a user-facing change?:

NONE

[netlify]

✅ Deploy Preview for gateway-api-inference-extension ready!

Name	Link
🔨 Latest commit	9fb3a03
🔍 Latest deploy log	https://app.netlify.com/projects/gateway-api-inference-extension/deploys/68d0f560df161c00081c1671
😎 Deploy Preview	https://deploy-preview-1615--gateway-api-inference-extension.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Frapschen
Once this PR has been reviewed and has the lgtm label, please assign nirrozenbaum for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @Frapschen. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kfswain]

Heya @Frapschen

Could I get a hand in understanding the value add? This PR doesn't seem to change the verbosity specified in our entire logging system, so I don't see how the strings enforce hierarchy of verbosity.

Specifically, I appreciate verbosity being distinct from semantic meaning. See point 2 here: https://github.com/go-logr/logr?tab=readme-ov-file#differences-from-daves-ideas

[Frapschen]

@kfswain Thank you for explaining about verbosity-levels and semantics, I can follow this design and revert to using numbers.

How about other changes, any suggestions?

[Frapschen]

Sorry, I just found that:

  -zap-devel
        Development Mode defaults(encoder=consoleEncoder,logLevel=Debug,stackTraceLevel=Warn). Production Mode defaults(encoder=jsonEncoder,logLevel=Info,stackTraceLevel=Error) (default true)
  -zap-encoder value
        Zap log encoding (one of 'json' or 'console')
  -zap-log-level value
        Zap Level to configure the verbosity of logging. Can be one of 'debug', 'info', 'error', 'panic'or any integer value > 0 which corresponds to custom debug levels of increasing verbosity
  -zap-stacktrace-level value
        Zap Level at and above which stacktraces are captured (one of 'info', 'error', 'panic').
  -zap-time-encoding value
        Zap time encoding (one of 'epoch', 'millis', 'nano', 'iso8601', 'rfc3339' or 'rfc3339nano'). Defaults to 'epoch'.

They are also included in the flagset. I'm a bit confused why we're using two flags to control log verbosity.

If the reviewer approves, I'd like to switch to one of the following approaches:

1. Use only Zap's built-in flag via opts.BindFlags(flag.CommandLine)
2. Use only our custom flag defined in var

I prefer option 1 over option 2. WDYT @kfswain