* Delay switch to new server until after JoinGame is sent.
Unfortunately, in some cases (especially vanilla Minecraft) some login
disconnects are sent after ServerLoginSuccess but before JoinGame.
We've been using ServerLoginSuccess but it has caused too many problems.
Now Velocity will switch to a stripped-down version of the play session
handler until JoinGame is received. This handler does very little by
itself: it simply forwards plugin messages (for Forge) and waits for the
JoinGame packet from the server.
This is an initial version: only vanilla Minecraft 1.12.2 was tested.
However this is the way Waterfall without entity rewriting does server
switches (which, in turn, is inherited from BungeeCord).
* Move to Gradle 5 and Error Prone.
Updating Checker Framework flagged numerous warnings, which have been
corrected. These probably involve type declarations lacking a nullness
annotation that appeared elsewhere.
The upstream feature this relies on will be gone in Netty 5.x and there
is probably more benefit in using the connection's event loop to connect
to Mojang's authentication servers.
As @creeper123123321 noted on Discord, the javadoc specifies "Matches all {@link Player}s whose names start with the provided partial name.".
With the current implementation, if there were two online players named Notch and Notch2, only Notch would be returned as a singleton Collection. This PR fixes this behavior by removing the `exactMatch` code.
While validating this is a good idea, it causes too many issues in
practice. We will still clean the server address but no validation is
performed on the address.
This sounds stupid, but YourKit really casts its net wide when it tries
to instrument usages of JDBC. Velocity doesn't use JDBC, and yet if you
run Velocity with YourKit (even without profiling active) you pay a
significant cost.
