Update a single InterruptedBuildAction rather than creating a second one

[jglick]

As noted in jenkinsci/remoting#802, I saw a build.xml that had two InterruptedBuildActions, each with one cause of interruption. The intention of causes being a list was presumably that there would be one action enumerating all causes, though the current behavior may be harmless if all callers in fact are prepared to query multiple actions.

jenkins/core/src/main/java/jenkins/model/queue/AsynchronousExecution.java

Line 76 in 60df855

* You might also want to call {@link Executor#recordCauseOfInterruption} on {@link #getExecutor}.

advertises that recordCauseOfInterruption may be called externally, which https://github.com/jenkinsci/workflow-job-plugin/blob/5e2896f2283418e36387d59fedc5a46f840a7668/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java#L405 in fact does.

jenkins/core/src/main/java/hudson/model/Executor.java

Lines 235 to 238 in 60df855

	for (CauseOfInterruption c : causes) {
	if (!this.causes.contains(c))
	this.causes.add(c);
	}

suggests that the list of causes is intended to not contain duplicates.

Testing done

Automated test, though it is not terribly realistic since freestyle builds only call recordCauseOfInterruption once, in

jenkins/core/src/main/java/hudson/model/Run.java

Line 1855 in 60df855

Executor.currentExecutor().recordCauseOfInterruption(Run.this, listener);

Proposed changelog entries

• N/A

Proposed changelog category

/label internal

Proposed upgrade guidelines

N/A

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, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[jglick]

Without fix, fails with

java.lang.AssertionError: 

Expected: is <[[one, two, three, four]]>
     but: was <[[one, two], [three, four]]>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
	at hudson.model.ExecutorTest.recordCauseOfInterruption(ExecutorTest.java:245)

[A1exKH]

LGTM.

[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!