Rework the event API

The Velocity event API, as currently designed, has some major flaws in its design that we should aim to correct for Velocity Polymer.

Handling of potentially blocking events

Status: Implemented with #384, thanks @Cybermaxke! It works essentially as I described, though the terminology is a bit different.

The original design choice for dealing with events that might potentially take too long in Velocity 1.x.x was to offload all event execution to a separate thread pool and execute the event handlers there. Unfortunately it is quite possible for this thread pool to be easily exhausted, Switching from the current fixed-size thread pool to a cached thread pool may help a little here, but it still poses issues. It also introduces context switching which may not be ideal for some users.

My current proposed solution is:

• All events will now fire on the event loop initially. This means relatively lightweight listeners can run on the Netty event loop and reduce latency.
• If there is a possibility for an event listener to do a task that can take some time, the event handler can choose to pause bubbling the event, perform the logic, and then resume bubbling the event.

Concrete implementations of events

Status: zml needs to do some refactoring for this, but event-impl-gen is what we plan to use to generate event implementations.

This concept was borrowed from Bukkit and as I have come to learn, is a very bad idea. This to some degree significantly complicated the transition from text to adventure, for instance.

For Velocity 2.0.0 we will take a page from Sponge and rework all Velocity events to use interfaces, then hide the actual event implementation in the proxy. So as to prevent duplication of code, we will try to auto-generate as much event-related code as possible.

Reconsider the event result system

Status: The result system will not be changed. There will be some reorganization, but most developers seem to need help with using it. Velocity 2.0.0 will add convenience methods that will set results for the user.

The event result system was introduced to combine the action to take as a result of an event and any associated actions to go with it. This has resulted in much confusion from plugin developers. I do not have a concrete strategy to handle this yet.

Consider adding a cause system ala Sponge

Status: This system isn't likely to add value since most events in Velocity already have a clear, fixed cause-and-effect relationship. We may reconsider this later if there is developer demand for it.

Start by reviewing the Velocity event API and the remaining concrete-event implementation refactor; the issue identifies interfaces and event-impl-gen as the planned entry points. Confirm which proposals remain open, then define completion around the stated Velocity 2.0.0 event design, since blocking-event handling and result-system changes are already marked resolved.