Allow pre-1.13 connections with modern forwarding

[p0t4t0sandwich]

I found this slight redundancy while backporting modern forwarding to Forge 1.7.10-1.12.2, and have verified that Velocity rejects player connections if the backend server has not implemented the necessary player info forwarding flow (as it would with any modern server that doesn't have modern forwarding configured correctly).

The statement in the comment:

If the proxy is configured for modern forwarding, we must deny connections from 1.12.2 and lower, otherwise IP information will never get forwarded.

No longer seems to be true, considering Velocity's LoginSessionHandler will disconnect the player with the message velocity.error.modern-forwarding-failed if the proxy doesn't receive the velocity:player_info LoginPluginMessagePacket.

The velocity.error.modern-forwarding-needs-new-client disconnect message is also somewhat misleading, as it's on the backend server software to support modern forwarding/have modern forwarding configured correctly.
To elaborate: if you're using ViaBackwards on a newer backend server you can connect with an older client and could still technically use modern forwarding without any issues client-side, since the LoginPluginMessagePacket and LoginPluginResponsePacket packets are only ever exchanged between Velocity and the backend server.

Long story short, this bit of code isn't necessary to enforce the modern forwarding spec.

This also somewhat opens the door to those who want to backport modern forwarding, excluding packet registration. I personally haven't thought of a nice way to handle that yet (since it doesn't abide by the Vanilla MC spec), so for the time being I may just create a proxy plugin that injects into the StateRegistry.

[electronicboy]

I mean, this is a weird are as protocol hacks are not something that we support; I'm dubious on the nature of removing a message which makes it fairly trivial to support a somewhat common misconfiguration that people have, protocol hacks don't tend to bump the protocol in a manner that velocity can even see it to attempt using a modern forwarding mechanism.

I am loosely open to not getting in the way of such hacks, but, it should be fairly opt in from servers doing stuff rather than removing the forward presentation which makes it clear why the connection can go on

[p0t4t0sandwich]

That's quite fair, I was too deep on the topic and didn't think of things from that angle. I could see how removing that check would make things far more confusing to the average user.

Not at all married to the name, but would a config flag like this suffice?

advanced.modern-forwarding-allow-legacy-connections (defaulting to false)

Additionally, would it be acceptable to add an opt-in config flag that could change LoginPluginMessagePacket and LoginPluginResponsePackets registered version from 1.13 to 1.7.2 to explicitly allow for back-ported solutions?
For example, something along the lines of:

advanced.modern-forwarding-register-legacy-login-packets (defaulting to false)