Revert "Improve breadcrumb bar accessibility"

[basil]

See this thread. The Jenkins core maintainers aspire to deliver First Customer Ship (FCS) quality all the time on the main branch. The integration of #6912 has destabilized the main branch, resulting in approximately a dozen pull requests to correct issues with the initial integration. When the main branch is not in a stable state, new problems are far more likely to be introduced, a timeless phenomenon described by Jeff Bonwick as the Quality Death Spiral. The overall quality of the delivered software, not any one project, is what matters; therefore, this PR reverts #6912.

There is past precedent for this: when the Jetty 10 upgrade was integrated, it destabilized the main branch. It was quickly reverted, then reintegrated later when all known issues had been addressed. The revert of #6912 is also intended to be temporary: once the issues caused by the original change are addressed (including JENKINS-70169, JENKINS-70255, and jenkinsci/design-library-plugin#182), we fully hope and expect for it to be reintegrated and delivered in its final form.

The original author of #6912 has offered a partial revert instead of a full one in #6912 (comment). It is unclear to me whether the partial revert would address JENKINS-70169, JENKINS-70255, and jenkinsci/design-library-plugin#182. If it addresses all three issues and is completed prior to the release of 2.383, this would address my concerns and this PR could be closed. If a partial revert does not address all three issues or if it is not completed prior to the release of 2.383, I would like to proceed with a full revert for 2.383 as in this PR.

Testing done

Built core with these changes and verified that the console output page looked the same as it did prior to #6912.

Proposed changelog entries

Restore breadcrumb navigation behavior from 2.374 and earlier.

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

Maintainer checklist

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

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

[timja]

-1

#7539 (comment)

[github-actions]

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