Call out body of main-panel using HTML comments

[jglick]

When looking at Jenkins HTML page responses as HTML, it is difficult to spot where the main body lies, as HTML for the header and footer portions can be quite long, and the main body is stuck deep in the middle of a very long line. This is particularly annoying when trying to diagnose a test failure where WebClient makes an API request but receives an HTML error page, 99% of which is junk.

Testing done

With this patch, it is much easier to find the relevant text:

…tons of stuff…<a href="/jenkins/user/support" class="model-link"><svg class="icon-md" xmlns="http://www.w3.org/2000/svg" aria-hidden="true" viewBox="0 0 512 512"><title/><path d="M256 48C141.31 48 48 141.31 48 256s93.31 208 208 208 208-93.31 208-208S370.69 48 256 48zm-50.22 116.82C218.45 151.39 236.28 144 256 144s37.39 7.44 50.11 20.94c12.89 13.68 19.16 32.06 17.68 51.82C320.83 256 290.43 288 256 288s-64.89-32-67.79-71.25c-1.47-19.92 4.79-38.36 17.57-51.93zM256 432a175.49 175.49 0 01-126-53.22 122.91 122.91 0 0135.14-33.44C190.63 329 222.89 320 256 320s65.37 9 90.83 25.34A122.87 122.87 0 01382 378.78 175.45 175.45 0 01256 432z" fill="currentColor"/></svg><span class="hidden-xs hidden-sm">support</span></a><a href="/jenkins/logout"><svg class="icon-md" xmlns="http://www.w3.org/2000/svg" aria-hidden="true" viewBox="0 0 512 512"><title/><path d="M160 256a16 16 0 0116-16h144V136c0-32-33.79-56-64-56H104a56.06 56.06 0 00-56 56v240a56.06 56.06 0 0056 56h160a56.06 56.06 0 0056-56V272H176a16 16 0 01-16-16zM459.31 244.69l-80-80a16 16 0 00-22.62 22.62L409.37 240H320v32h89.37l-52.68 52.69a16 16 0 1022.62 22.62l80-80a16 16 0 000-22.62z" fill="currentColor"/></svg><span class="hidden-xs hidden-sm">log out</span></a></div></header><div id="breadcrumbBar" class="jenkins-breadcrumbs" aria-label="breadcrumb"><ol class="jenkins-breadcrumbs__list" id="breadcrumbs"><li class="jenkins-breadcrumbs__list-item"><a href="/jenkins/" class="model-link">Dashboard</a></li><li class="children" data-href="/jenkins/"></li></ol></div><div id="page-body" class="app-page-body app-page-body--two-column clear"><div id="side-panel" class="app-page-body__sidebar "><div id="yui-logreader" style="margin-top:1em"></div></div><div id="main-panel"><a id="skip2content"></a><!--
start of main content ⇒
--><h1>Error</h1><p>something must be nonzero or whatever<!--
⇐ end of main content
--></div></div><footer class="page-footer jenkins-mobile-hide"><div class="page-footer__flex-row"><div class="page-footer__footer-id-placeholder" id="footer"></div>…lots more stuff…
    Jenkins 2.xxx-SNAPSHOT
  </button><template><div class="jenkins-dropdown"><template data-dropdown-icon="&lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot; xmlns:xlink=&quot;http://www.w3.org/1999/xlink&quot; aria-hidden=&quot;true&quot; height=&quot;463px&quot; version=&quot;1.1&quot; viewBox=&quot;0 0 413 463&quot; width=&quot;413px&quot;&gt;    &lt;g fill=&quot;none&quot; fill-rule=&quot;evenodd&quot; stroke=&quot;none&quot; stroke-width=&quot;1&quot;&gt;        &lt;path d=&quot;M324.9,27.6745418 C325.214,27.9125418 325.53176,28.1557818 325.853076,28.4041026 …way more stuff…

Does not seem to interfere with web rendering (checked in Firefox), and also makes View Source more pleasant.

Proposed changelog entries

• N/A

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