[JEP-237] Do not support shortening of HMAC code on FIPS mode

[SujathaH]

HMACConfidentialKey supports an option to return trimmed HMAC code. Usage of trimmed code can cause issues when used from security context. This change is to throw an exception when callers try to get trimmed HMAC code on FIPS mode and also
this change assumes that Legacy Token is disabled on FIPS mode. There is a plan to remove support for Legacy Token and enhancement JENKINS-71573 exists for same. Hence, Legacy Token flag needs to be disabled on FIPS mode for this change to work successfully.

Verified across all the plugins and found there are no plugins which are using the truncated HMAC code.
The only impact is on Legacy Token in Jenkins Core

See JEP-237.

Testing done

Verified exception is thrown when HMAC Key is being created with length less than original length of HAMC code on FIPS mode
Verified trimmed code is returned when HMAC Key is being created with length less than 32 on non FIPS mode

Proposed changelog entries

Prevent trimming HMAC codes (using HAMCConfidentialKey) when running in FIPS mode only.

Proposed upgrade guidelines

N/A

Submitter checklist

Beta Give feedback

1. The Jira issue, if it exists, is well-described.
2. The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@jtnord

Before the changes are marked as ready-for-merge:

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[jtnord]

the unit tests look like they will pass when they should fail.

Also please leave links to any plugins or code that will be impactec by this change in the summary.

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[DONGSIK2026KIM]

how about make a var as "Hello World"?