Use ABORTED from Run.reload

[jglick]

Resolving a comment I made a decade ago (!) in b55c157: if a non-Pipeline build is interrupted by a controller restart, ABORTED status (used for all sorts of sudden interruptions unrelated to the logical build steps) is more natural than FAILURE (a problem in a specific step preventing the build from proceeding). This is also more consistent with Pipeline builds, or node blocks, that fail to resume for various reasons when normally they could.

Testing done

None; apparently this does not have test coverage? Could add some if it seems valuable.

Proposed changelog entries

• Non-Pipeline builds interrupted by a controller restart will now be marked as aborted rather than failed.

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

Maintainer checklist

Edit tasklist title

Beta Give feedback Tasklist Maintainer checklist, more options

• Rename
• Copy markdown
• Delete tasklist

Delete tasklist

Delete tasklist block?

Are you sure? All relationships in this tasklist will be removed.

Cancel Delete

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.

   There are at least two (2) approvals for the pull request and no outstanding requests for change.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.

   Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
3. Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood.

   Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
4. Proper changelog labels are set so that the changelog can be generated automatically.

   Proper changelog labels are set so that the changelog can be generated automatically.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
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](https://github.com/jenkinsci/jenkins/pull/4387)).

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

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
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](https://issues.jenkins.io/issues/?filter=12146)).

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

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove

Add item to Maintainer checklist

[StefanSpieker]

I like that change, I was more than once asked why it says failed instead of aborted in case of controller restarts.

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