Update bundled trilead-api to 2.84.86.vf9c960e9b_458

[daniel-beck]

See SECURITY-3333 and https://github.com/jenkinsci/trilead-api-plugin/releases/tag/2.84.86.vf9c960e9b_458

Testing done

Un-@Ignored LoadDetachedPluginsTest#noUpdateSiteWarnings. Failed before this change, passed after.

Proposed changelog entries

• Update bundled Trilead API Plugin to 2.84.86.vf9c960e9b_458.

Proposed upgrade guidelines

N/A

Submitter checklist

Beta Give feedback

1. 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.
2. There is automated testing or an explanation as to why this change has no tests.
3. For dependency updates, there are links to external changelogs and, if possible, full differentials.

Desired reviewers

@mention

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).

[MarkEWaite]

/label ready-for-merge

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

[MarkEWaite]

@daniel-beck I think that this should be considered as an LTS candidate because it is updating a component to avoid a security warning for some use cases. Is my thinking correct and if so, should this be proposed for 2.440.2?

Would you be willing to create the Jira ticket that can be used to track it as an LTS candidate or would you prefer that I create that ticket?

[daniel-beck]

@MarkEWaite I have no preference. Feel free to do it.

[MarkEWaite]

JENKINS-72856 has been created.

@krisstern I'm not sure if it is too late to consider that as a candidate backport for 2.440.2. If it is not selected for backport to 2.440.2, it should be considered as a possible backport for 2.440.3.

@timja do you have strong feelings one way or the other on this proposed backport to 2.440.2?

[krisstern]

Hi @MarkEWaite,

Either way is fine with me. I have been waiting for @timja's response to see what his opinion on this matter is.

[MarkEWaite]

@krisstern I'm not sure if it is too late to consider that as a candidate backport for 2.440.2. If it is not selected for backport to 2.440.2, it should be considered as a possible backport for 2.440.3.

I think we should reject it for 2.440.2 and consider it for 2.440.3. I don't think that the use case is critical enough to justify another backporting pull request.