applying dev context configuation to test stage

[ravisinha0506]

Issue #, if available:

Description of changes:
Most of the dev stages are configured as test stage. As per existing code, test stage utilizes prod configuration. Hence, applying dev stage configuration to test stage as well

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[ellistarn]

The more time I spend with zap, the more I want to just always use the production logger to standardize tools. It has a nice side effect of leading decs towards making logs that will be readable in production.

Thoughts?

[JamesGAWS]

My 2c is that there's a lot of value in being able to configure lower logging levels for troubleshooting application behavior. I think having the ability to explicitly set logging level (instead of using stage as a proxy) has the advantage of being able to activate debug logging in select production scenarios where there's a need to debug customer specific behavior.

[ellistarn]

My 2c is that there's a lot of value in being able to configure lower logging levels for troubleshooting application behavior. I think having the ability to explicitly set logging level (instead of using stage as a proxy) has the advantage of being able to activate debug logging in select production scenarios where there's a need to debug customer specific behavior.

Completely agree. If we're just using development to control log level, we should revisit this assumption. The main difference that I am familiar with is stack traces, console vs json, and log level.

I like James' suggestion as it keeps us as "production-like" as possible in development, while giving us the control we need.

[ellistarn]

related: https://github.com/kubernetes-sigs/karpenter/blob/34398e54f24b281619bf39e728480b422938e8b3/pkg/operator/options/options.go#L123