Increase minimum required Remoting version from 4.13 to 3107.v665000b_51092

[basil]

The current minimum Remoting version (4.13) is now 2 years and 4 months old. This PR bumps the minimum Remoting version to 3107.v665000b_51092, which is 1 year and 5 months old, effectively raising the minimum Remoting version by 1 year. I still think that ~1.5 years is a generous amount of time for people to upgrade agents, and it benefits the ecosystem to have agents running on a recent version of Remoting with bug fixes and dependency updates. We have had no issues previously raising the minimum Remoting version in #7340, #6671, and #8484.

Testing done

This use case is covered by test automation; specifically, jenkins.slaves.OldRemotingAgentTest, jenkins.slaves.UnsupportedRemotingAgentEscapeHatchTest and jenkins.slaves.UnsupportedRemotingAgentTest. I ran all of these tests (and more) locally with:

mvn clean verify -Dtest=hudson.slaves.ChannelPingerTest,hudson.slaves.JNLPLauncherTest,hudson.slaves.PingThreadTest,hudson.slaves.SlaveComputerTest,jenkins.agents.WebSocketAgentsTest,jenkins.security.AgentToControllerSecurityTest,jenkins.security.CustomClassFilterTest,jenkins.slaves.OldRemotingAgentTest,jenkins.slaves.RemotingVersionInfoTest,jenkins.slaves.UnsupportedRemotingAgentEscapeHatchTest,jenkins.slaves.UnsupportedRemotingAgentTest

Proposed changelog entries

Increase the minimum required Remoting version to 3107.v665000b_51092 (released on February 2, 2023).

Proposed upgrade guidelines

Increase the minimum required Remoting version to 3107.v665000b_51092 (released on February 2, 2023). When an agent with a Remoting version older than 3107.v665000b_51092 connects to the Jenkins controller, the agent connection is rejected. Ensure that all agents are running a recent version of Remoting prior to upgrading. Agents with unsupported Remoting versions can be allowed to connect to the controller by setting the hudson.slaves.SlaveComputer.allowUnsupportedRemotingVersions system property to true.

Desired reviewers

@mention

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

[MarkEWaite]

Thanks!

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