feat: replace mockEnvVars bool with RenderEnvVarsMode in GetContentFromFiles

[mheap]

Summary

Adds newGetContentFromFilesWithEnvVars method with a typed RenderEnvVarsMode, adding a new EnvVarsSkip mode that skips template rendering entirely.

Changes

• Added RenderEnvVarsMode type with three constants to pkg/file/template.go:
  • EnvVarsExpand — expands env vars (replaces false)
  • EnvVarsMock — returns var names as values (replaces true)
  • EnvVarsSkip — skips template rendering entirely (new)
• Updated GetContentFromFilesWithEnvVars, getContent, readContent, and renderTemplate to use the new type
• Updated all callers in tests and integration tests

Usage

// Skip env var expansion entirely
content, err := file.GetContentFromFilesWithEnvVars(filenames, file.EnvVarsSkip)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 87.50000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.90%. Comparing base (484667e) to head (9c97094).

Files with missing lines	Patch %	Lines
tests/integration/test_utils.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #444      +/-   ##
==========================================
+ Coverage   28.81%   28.90%   +0.09%     
==========================================
  Files         121      121              
  Lines       16517    16524       +7     
==========================================
+ Hits         4760     4777      +17     
+ Misses      11138    11129       -9     
+ Partials      619      618       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Prashansa-K]

Note: This is a breaking API change — callers must update from bool to RenderEnvVarsMode

We will have to push for major version release in that case, which would require a lot of changes. Is this really worth the effort?
What is the exact usecase for this? Found this: https://kongstrong.slack.com/archives/C04349E4KRC/p1775115564350019

[mheap]

@Prashansa-K I don't think we need the major version bump here. There is only one consumer (deck) which we also own.

If you feel strongly, I can add a new method which has the new signature and make the old one an alias

[Prashansa-K]

What if we make a new config struct for this or utilise the existing RenderConfig struct to add the new modes? deck can set the config and the GetContent* interfaces can use them without breaking contracts?

We use a similar model for dumpConfig too.

This would make the implementation future-proof as well.

[Prashansa-K]

I can add a new method which has the new signature and make the old one an alias

This works too. Whatever is easy and not confusing can be done.