Enforce FIPS compatible Sprig functions for template rendering

[sukhil-suresh]

Change Overview

This is part of the effort to enable a FIPS-compatible Kanister. The github.com/Masterminds/sprig library is used by
Kanister for rendering blueprint templates. Some of the available sprig template functions are not FIPS-compatible and
therefore their usage has been disallowed.

• Added a FIPS-compatible TxtFuncMap()
• Updated usages of TxtFuncMap() to use the FIPS-compatible version
• Updated docs to indicate unsupported functions

Pull request type

• 🌈 Refactoring
• 🌻 Feature

Test Plan

• ⚡ Unit test

Verified the newly added unit tests for template rendering pass:

=== RUN   TestFipsOnlySprigSuite
OK: 2 passed
--- PASS: TestFipsOnlySprigSuite (1.63s)
PASS

[kidgilson]

How are we ensuring that future bumps of sprig are analyzed to see whether anything here needs to be added?

[sukhil-suresh]

The kanister project uses an older v2.22.0 Sprig version but we have vetted against v3.2.3. I left the comment for easy tracking of when the replacement functions were added but it seems to have triggered fair upgrade concerns :)
Having a runtime error for a mismatch doesn't seem like a great user experience. Wondering if a custom linter rule is possible.

[kidgilson]

Yea, maybe we need to add a file like fips.txt where we have the name of the package from go.mod and the version it's vetted too, and if go.mod != fips.txt then the CI checks throw an error that those packages need to be looked at and the fips.txt version should be updated. A little like the .tool-versions file.

[kidgilson]

How do we ensure we use this file in place of sprig in the future?

[sukhil-suresh]

I can only think of exploring a custom linter rule for this purpose. We need an agreement on the solution and if it needs to be addressed in this PR.

[kidgilson]

Yea, I don't think this comment or #2708 (comment) should block this PR. I brought it up as a concern but if we agree to address it moving forward then that's fine.