Issue warning, if possible, when behavior changes due to backend plugin handling

[A248]

In the pre-existing Velocity API, canceling a chat event prevents it from being sent to the backend servers. Chat canceled on the proxy is therefore invisible to Bukkit plugins. However, using SignedVelocity fundamentally alters this behavior by forwarding all chat events, even if canceled, to the backend servers. While this makes the plugin work, it is a behavioral change from the prior status quo, and leaks the abstraction SignedVelocity employs to shore up chat handling in a post-1.19.4 world.

This can be confusing for users who are acquainted to the previous behavior. For example, it may cause certain proxy plugin features to stop working when switching from pre-1.19.4 to post-1.19.4 with SignedVelocity, since the behavior of chat events is now different.

Most of the time, however, uncanceling a canceled chat event doesn't make sense. Fortunately, SignedVelocity is in the unique position of knowing exactly when a chat event was canceled by the proxy but uncanceled by the backend server. I therefore propose SignedVelocity add another listener on EventPriority.HIGHEST to log a brief warning if behavior has fundamentally changed as a result of a backend plugin uncanceling the event. It should be relatively straightforward given you already have a queue of chat data, so no additional data structure overhead would be incurred. If you want to avoid annoying users, the brief warning can be one-time, or it can be disabled by a config option. However, I argue it should be enabled by default, because it presents a behavioral change from the typical Velocity API proxy plugins are used to.

[4drian3d]

I missed commenting here, but the real problem here is that some plugins use deprecated chat events that are executed before Paper's AsyncChatEvent, so, it may be that a plugin handles the chat with a deprecated event before SignedVelocity checks if a message was modified from Velocity.
To mitigate this, I added a warning message in the console when starting the plugin mentioning plugins that use these legacy events.

[A248]

Adrian, I'd like to politely ask you to revisit my message. It's possible for plugins to listen only to the AsyncChatEvent yet still cause a behavioral inconsistency with respect to pre-1.19.4 chat handling.

An example of this would be a Paper plugin that listens to AsyncChatEvent on EventPriority.HIGHEST, cancels the event, and sends the formatted message to all players anyway. Before SignedVelocity, if the chat was canceled on the proxy, it would not reach the backend server, and no message would occur. After SignedVelocity and 1.19.4, if the chat was canceled on the proxy, it would still be sent to the Paper plugin.

[4drian3d]

I will implement a system similar to the one I have in KickRedirect to detect these cases for the next version

[TheIceNinja]

did u fix the issue?