JENKINS-60630: Add GitSCMFileSystem support for EnvVar expansion

[rayvincent2]

JENKINS-60630 - Perform EnvVars expansion on GitSCMFileSystem BranchSpecs

Updates the GitSCMFileSystem class to support expanding environment variables on provided BranchSpecs.

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. This is simply a reminder of what we are going to look for before merging your code. If a checkbox or line does not apply to this pull request, delete it. We prefer all checkboxes to be checked before a pull request is merged

• [x] I have read the CONTRIBUTING doc
• [x] I have referenced the Jira issue related to my changes in one or more commit messages
• [x] I have added tests that verify my changes
• [x] Unit tests pass locally with my changes
• [x] I have added documentation as necessary
• [x] No Javadoc warnings were introduced with my changes
• [x] No spotbugs warnings were introduced with my changes
• [x] Documentation in README has been updated as necessary
• [x] Online help has been added and reviewed for any new or modified fields
• [x] I have interactively tested my changes
• [x] Any dependent changes have been merged and published in upstream modules (like git-client-plugin)

Types of changes

What types of changes does your code introduce? Put an x in the boxes that apply. Delete the items in the list that do not apply

• [ ] Dependency or infrastructure update
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Further comments

One concern that I have is the approach for retrieving Environment Variables for the running job. I referenced the lastBuild when isBuilding() is true. This will create a race condition during concurrent builds (depending on how the SCM API is used) where all running builds will only use the environment variables for the last one initiated. I've confirmed this on my local Jenkins server.

The only way I see to resolve this is to update the SCM API's SCMFileSystem.Builder.build api to allow for a new override:

public abstract SCMFileSystem build(@NonNull Run<?,?> run, @NonNull SCM scm, @CheckForNull SCMRevision rev)
                throws IOException, InterruptedException;

This would allow anyone to reference the exact build that's being executed and easily infer the Item needed as well. In addition, the existing method can use the lastBuild as a best effort.

Before diving into dependent libraries, I wanted to get another eye on this. As is, this works great aside from the potential issue of concurrent jobs.