Add PlayerConfigurationEvent and PlayerEnteredConfigurationEvent

[Gerrygames]

This addresses issues #1367 and #1368

• Configuring the player (i.e. sending resource packs) should now be done in the new PlayerConfigurationEvent.
• The new PlayerEnteredConfigurationEvent is called when a player acknowledged the switch to configuration state.
• The PlayerEnterConfigurationEvent is no longer called twice. It is now called when the backed wants to reconfigure the player. Velocity will wait (up to 5 seconds) for this event and only then ask the client to switch to configuration state.
• The PlayerFinishConfigurationEvent should no longer be used to configure the player (i.e. sending resource packs). This is because since 1.20.5 the backend server can't send keep alive packets between switching state anymore and the connection will thus time out. Velocity will only wait 5 seconds for this event.
• Improved java docs. Feedback would be appreciated.

[Timongcraft]

Is it intentional that the new PlayerConfigurationEvent is only called for the initial configuration and not for subsequent ones, unlike the (old) PlayerFinishConfigurationEvent?

[Gerrygames]

No that's a mistake then. I will investigate that later.

[Timongcraft]

I just noticed that the Javadoc for the PlayerEnterConfigurationEvent specifies that it is called before the client enters the configuration state. However, it also states that it only waits 5 seconds because the backend can't keep the connection alive during the configuration state. Since the client is not in the configuration state at that moment, does this mean that the backend will terminate the connection because it requested the change to the configuration state? If so, I think the wording is a bit confusing.

[Gerrygames]

The "clientbound" connection between velocity and the backend is already in configuration state but the clientbound connection between velocity and the client is still in play state. The java doc states that the backend can't keep the connection alive during state changes which is correct. If you have any better wording for it, you're welcome to suggest it.

[Timongcraft]

How about this?

 * <p>Velocity will wait for this event before asking the client to enter configuration state.
 * <br>However, for the backend server, the player is already in the configuration state. Since the server cannot maintain the connection during state changes,
 * Velocity will only wait for a maximum of 5 seconds.</p>

The "clientbound" connection between velocity and the backend is already in configuration state but the clientbound connection between velocity and the client is still in play state. The java doc states that the backend can't keep the connection alive during state changes which is correct. If you have any better wording for it, you're welcome to suggest it.

[Timongcraft]

No that's a mistake then. I will investigate that later.

Have you found anything?

[Gerrygames]

No that's a mistake then. I will investigate that later.

Have you found anything?

Fixed by d999ee2