[JENKINS-16005] Use system temp directory for CommandInstaller scripts

[meetgoti07]

Fixes #13136

AbstractCommandInstaller.performInstallation() was calling createTextTempFile() with the default inThisDirectory=true, causing it to create temp script files in the tool's installation directory (e.g., /usr). This fails when Jenkins doesn't have write access to that directory.

Changed to use createTextTempFile(..., false) to create temp files in the system temp directory (java.io.tmpdir) instead.
Added explicit dir.mkdirs() call to ensure the tool installation directory exists before running the script.

Testing done

Manually tested by:

1. Configured a JDK tool with "Install automatically" using "Run Command"
2. Set Tool Home to /usr (a read-only directory on macOS)
3. Created a Freestyle job using this JDK
4. Before fix: Build failed with Failed to create a temp file on /usr
5. After fix: Build succeeded, temp script created in system temp directory (/var/folders/.../T/hudsonXXX.sh)

Screenshots

Before

After

Proposed changelog entries

• Do not fail builds when the tool installation directory is read-only.

Proposed changelog category

/label bug

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• 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.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, 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).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@daniel-beck @krisstern

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

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• 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).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

[MarkEWaite]

Fixes #16021

The JENKINS-16021 issue is unrelated to this change. What is the issue that you are trying to resolve?

[meetgoti07]

@MarkEWaite Sorry for the confusion, I accidently mentioned Legacy Jira Issue number.
I have updated the issue number.

[MarkEWaite]

Thanks for the pull request and thanks especially for outlining how you tested interactively. That is exactly the type of pull request description that we need.

I can duplicate the test failure that is reported on ci.jenkins.io. I run the command:

mvn clean -Dtest=InstallerTranslatorTest,EnvVarsTest,AboutJenkinsTest verify

I've made the pull request a draft pull request so that you can identify the cause of the test failure and either fix the test or make a change to the production code that both passes the automated test and passes your interactive tests. Once you've done that, please mark the pull request as "Ready for Review".

[meetgoti07]

@MarkEWaite
Thank you for your suggestion. This addresses the issue I was trying to understand.

[MarkEWaite]

@meetgoti07 it is generally best for maintainers and other reviewers if you do not force push changes. When you force push a change, it breaks the connection between earlier comments and their matching commits. In this case, the force push did no harm because there were no comments on prior commits. However, as you continue to contribute, you'll find it best to leave the original commit and push a new commit. You can always label the pull request as "squash-merge-me" to assure that the incremental commits do not appear in the final history.

[meetgoti07]

@MarkEWaite Got it, thank you for the guidance. I will avoid force pushing and use incremental commits going forward. I have also fixed the test failure issue.