[JENKINS-75683] re-introduce actions for Jenkins with custom action.jelly

[jtnord]

JENKINS-75683
Actions without a URL but a custom action.jelly were not shown correctly in the header.

NB: this is built on top of #10729 adn the changes for this PR are all contained in b091ea21533865f26ee747bec2930bb1f730465d

This re-introduces them and allows custom rendering of actions again (by using an action.jelly).
Actions that require a confirmation (and post) work.

Things still to do,
* task taglib needs to be adjusted to style correctly when tasks are in the header
~ ** nested tasks need to be handled appropriately (they are included only in sub pages, but see previous bullet point)~
* remove the url hack.
* Fix the nested tasks so that the parent still contains the correct tooltip.
* use the dropdown for nested elements..?
* the task styling in the dropdown is oh so wrong...
* check the rendering when inside the "overflow" icon dropdown.

• update screen shots
  * run ATH

Screen Shots

Note

the after screenshots include the hamburger introduced in https://github.com/jenkinsci/jenkins/pull/10729which is a requirement for this change.

Before

with overflow menu:

without overflow menu:

issues:

• The actions highlighted in Yellow have an action.jelly that would hide the actions (but they show up).
• The actions highlighted in Ornage have an action.jelly that includes sub tasks that should be shown.
• There is no element/icon/action for the purge-build-queue plugin

After

no current action:

no current action expanded hamburger:

current action with subtasks:

current action with hamburger: (action removed from hamburger)

Support for tasks that require confirmation:

The above demonstrate that an Action with an action.jelly are now handled correctly.

• Actions are present if their action.jelly says they should be regardless of the lack of an icon from the java side.
• Actions that where hidden in the action.jelly no longer show
• Actions with subtasks are correctly allow you to interact with subtasks when the action is the current action in the page.

See JENKINS-75683.

Testing done

Proposed changelog entries

• RootActions that used custom rendering (action.jelly) are once again visible in the header and behave appropriately.

• RootActions that use jelly to show/hide are correctly hidden in the header

• RootActions with sub tasks now show the subtasks as a dropdown when in the correct context

• Proposed upgrade guidelines

  N/A

  Submitter checklist

  • The Jira 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.
  • 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

  @mention

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

[scherler]

FYI PR To fix the styling jtnord#2

[jtnord]

For some reason this fails to show RootActions when in a View. When used in conjuction with #10676 RootActions show neither in Folders nor Views

Seems to be an issue with the specific action that is trying to infer things from the current URL, and making assumptions that no longer hold true.

[MarkEWaite]

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

/label ready-for-merge

[A1exKH]

LGTM.

[github-actions]

Please take a moment and address the merge conflicts of your pull request. Thanks!