Ensure RealJenkinsRule tests always start on a free port

[Vlatombe]

RealJenkinsRule tests running in parallel or involving multiple Jenkins instances have been flaky because the "random" port allocation can lead to attempts to use ports which are in fact already used.

This work relies on jenkinsci/winstone#174 to ensure the Jenkins instance started by RealJenkinsRule starts on a random free port (allocated by winstone/jetty). Subsequent restarts (if there are) will reuse the same port to ensure Jenkins URL stability.

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jglick]

Do we even need jenkinsci/winstone#174? Just pass --httpPort=0 and have RealJenkinsRule.Endpoint.register write the port number to a well-known file in $JENKINS_HOME. (Pass the selected port number on subsequent starts since some tests expect the Jenkins URL to be stable across sessions. Reintroduces the race condition for tests which do use multiple sessions, but these are in the minority and I think we have no alternative since you cannot just reserve a port without binding it.)

Mentioned previously in #347 (comment). That discussion diverged into whether RealJenkinsRule.getUrl needed to be supported prior to first startup for some tests. But this PR already breaks that semantics, and has no advantage that I can see over register, but the clear disadvantage of only working with new Jenkins versions.

There was also a discussion of acceptance-test-harness, and perhaps ATH could benefit from the new Winstone feature (I have not studied that case), but this does not mean RealJenkinsRule needs to rely on it. Am I missing something?

[Vlatombe]

Correct, for RJR we could probably take the route you propose to avoid waiting for the next LTS.

[jglick]

I tried to prototype that but hit a wall—there is no apparent way from inside Jenkins code to tell which port Jetty started on, without having a HttpServletRequest. The JUnit JVM could parse the stdio of the process looking for messages like

o.e.j.server.AbstractConnector#doStart: Started ServerConnector@4201c465{HTTP/1.1,[http/1.1]}{127.0.0.1:32955}

but that does not seem reliable.

[Vlatombe]

I will lift draft state as soon as Jenkins 2.346 LTS is out.

[jglick]

#348 (comment) again. Is it feasible to make this work when on newer Jenkins versions but fall back to the previous behavior? Otherwise rollout will be a headache since Dependabot POM updates will break nearly every plugin.

[Vlatombe]

I can probably adapt some of what I've done for the ath...

[jglick]

Looks right.

[jglick]

Ready for release?