Remove old, deprecated protocols.

docs/protocols.md

@@ -27,77 +27,6 @@ If stronger algorithms are needed (for example, AES with 256-bit keys), the [JCE
 
 Protocol uses non-blocking I/O wherever possible which removes the performance bottleneck of the <code>JNLP3-connect</code> protocol.
 
-## Deprecated protocols
-
-All protocols below are not recommended for the production use.
-They have been deprecated and replaced.
-
-:exclamation: Disclaimer:
-Deprecated protocols are not maintained in the Jenkins project.
-New bugfix and performance enhancement proposals will be reviewed and probably integrated, 
-but confirmed protocol-specific issues will be closed and added to Errata.
-
-### JNLP1-connect
-
-* Status: Replaced by `JNLP2-connect`
-
-The agent sends the master the name it wants to register as and the computed HMAC of the agent name.
-If accepted the master will reply with a confirmation response.
-Then the channel gets established.
-
-#### JNLP1-connect Errata
-
-* NIO is not supported by the protocol.
-It may cause performance issues on large-scale instances.
-
-### JNLP2-connect
-
-* Status: Replaced by `JNLP4-connect`
-
-This is the advanced versions of the <code>JNLP1-connect</code> protocol. 
-On successful connection to the master the agent will receive a cookie from the master, which the agent stores.
-
-If the agent needs to reconnect it will send the same cookie as part of the new connection request. 
-The master can use the cookie to determine if the incoming request is an initial connection request 
-  or a reconnection and take appropriate action.
-
-The protocol supports the non-blocking I/O, which improve the performance of the communication channel.
-
-#### JNLP2-connect Errata
-
-* [JENKINS-31735](https://issues.jenkins-ci.org/browse/JENKINS-31735), [JENKINS-24155](https://issues.jenkins-ci.org/browse/JENKINS-24155) - `NioChannelHub` thread dies sometimes without obvious reason
-* ...
-
-The list is not complete. 
-Check the bugtracker for more issues. 
-
-### JNLP3-connect
-
-* Status: Replaced by `JNLP4-connect`
-* Introduced in: Remoting 2.53, [JENKINS-26580](https://issues.jenkins-ci.org/browse/JENKINS-26580)
-* The protocol is disabled by default in Jenkins
-* **Not recommended** for use since the <code>JNLP4-connect</code> release
-
-This protocol aims to improve security of JNLP-based agent. 
-Both the master and the agent securely authenticate each other and then setup an encrypted channel.
-
-The protocol does not support non-blocking IO.
-For each connection a new thread is being created, and it leads to the performance degradation or
-  even Denial of Service on highly loaded Jenkins masters.
-There are also some reported issues regarding the Remoting 3 stability on particular systems.
-
-#### JNLP3-connect Errata
-
-Below you can find the list of known `JNLP3-connect` issues.
-There is no plan to fix these issues, usage of `JNLP4-connect` is the recommended approach.
-
-* [JENKINS-37302](https://issues.jenkins-ci.org/browse/JENKINS-37302) - 
-JNLP3 challenge response generates invalid string encoding, the check may fail randomly.
-* [JENKINS-33886](https://issues.jenkins-ci.org/browse/JENKINS-33886) -
-On some configurations only one JNLP3 agent per IP address can be connected.
-* [JENKINS-34121](https://issues.jenkins-ci.org/browse/JENKINS-34121) -
-JNLP3 cannot be used on IBM Java, which doesn't support AES/CTR/PKCS5Padding.
-
 ## Plugin protocols
 
 ### Remoting Kafka Plugin